Enable variants for specific ports in variants.conf

[Ionic (Mihai Moldovan)]

Currently, variants.conf only provides the possibility to globally enable or disable variants.

I'm proposing a feature letting users define port specific variants in this file too, similar to Gentoo's package.use or use.conf file(s), though not necessarily as sophisticated.

Basically it would be really nice to turn variants on and off in the variants.conf file for specific ports and globally, without fiddling with them on the command line.

Thus, I propose following syntax:

portname +variant1 -variant2 +variant3 +variant4 -variant5

Or, if that's more convenient,

portname variant1 -variant2 variant3 variant4 -variant5

We can retain the global variants definition by using the virtual portname "all", as in

all +universal

or

all universal

The upgrade option --enforce-variants SHOULD check for changed variants definitions and rebuild packages accordingly. Without specifying it, upgrade SHOULD NOT rebuild packages because of variants changes only.

However, is a port is already outdated, the upgrade command SHOULD update the specific port using the variants defined in there, but MUST NOT use the variants defined when previously installed.

Once this is in place, we COULD drop specifying variants on the command line. Retaining the functionality is fine too, but if so, global variants, package specific variants and variants defined on the command line SHOULD be merged and "variant conflicts" "resolved", with this priority:

cmdline >> specific >> global

I guess the current behavior is cmdline >> global, so specific variants would come between this and override any globally set variants.

[ryandesign (Ryan Carsten Schmidt)]

I don't understand why specifying per-port variants in a variants.conf file is more desirable than specifying per-port variants on the command line.

[Ionic (Mihai Moldovan)]

Several reasons:

It's easy to grep the file to see which ports use some specific variant or grep the file for a specific port.

Also, using this you can change variants for several ports at once and just rebuild the affected packages by running port upgrade --enforce-variants for instance.

[danielluke (Daniel J. Luke)]

Replying to ionic@…:

Several reasons:

2 reasons?

It's easy to grep the file to see which ports use some specific variant or grep the file for a specific port.

it's easy to grep the output of 'port installed' to see which ports use some specific variant or grep (or specify) the output for a specific port.

Also, using this you can change variants for several ports at once and just rebuild the affected packages by running port upgrade --enforce-variants for instance.

This might be useful, but I've never wanted/needed it.

Remember, that variants should be kept to a minimum anyway...

[Ionic (Mihai Moldovan)]

Replying to dluke@…:

2 reasons?

At least that's what came into my mind so far, yeah. :)

it's easy to grep the output of 'port installed' to see which ports use some specific variant or grep (or specify) the output for a specific port.

Yes, but port installed takes "ages" to process (~2 seconds on my machine), whereas grep variants.conf is "instant". :)

This might be useful, but I've never wanted/needed it.

Oh I did on several occasions, for instance when fiddling with universal because of different circumstances where I did need 32bit libs too (a mess...) or tried to enable GTK's aqua interface... and disable it again as it sucked.

Remember, that variants should be kept to a minimum anyway...

That may be true, but while we have it, why not improve this feature's handling? :)

[ryandesign (Ryan Carsten Schmidt)]

Replying to ionic@…:

Yes, but port installed takes "ages" to process (~2 seconds on my machine), whereas grep variants.conf is "instant". :)

"port installed" used to take ages (minutes) but this was dramatically improved to now only take seconds. I think this is completely acceptable performance.

That may be true, but while we have it, why not improve this feature's handling? :)

From what I understand this would make MacPorts more similar to Gentoo Portage, but I am not yet convinced it would be an improvement.

[webmaster@…]

Actually, there is a very good reason for this: If a package requires a dependency to be built with a certain variant, this package will always fail when using port upgrade outdated and require the dependency to be installed manually with the variant again before calling upgraded outdated again.

For example: pymol requires tk to be installed with - quartz. Now if I run upgrade outdated and both pymol and tk are upgraded, pymol will fail and require me to install tk manually with -quartz. Then I need to run upgrade outdated again which is very annoying. Actually I believe this is the reason why gentoo introduced the per package configuration in the first place.

[mp@…]

Here's another (good?) reason for the requested change: The Puppet configuration management tool currently cannot handle variants because its notion of packages features only version numbers and the variants don't fit in there. The workaround is to use the variants.conf file. That fails if you need one port with a particular variant and another one without it.

When adding this req, it would be great to maintain configuration BC. So I'd take "+foo +bar" as defaults for "all" ports and only a new spec like "someport: +bar +baz -foo" to apply only to "someport" (in this case, add bar and baz and drop the default foo).

[alexkowel@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Replying to webmaster@…:

Actually, there is a very good reason for this: If a package requires a dependency to be built with a certain variant, this package will always fail when using port upgrade outdated and require the dependency to be installed manually with the variant again before calling upgraded outdated again.

For example: pymol requires tk to be installed with - quartz. Now if I run upgrade outdated and both pymol and tk are upgraded, pymol will fail and require me to install tk manually with -quartz. Then I need to run upgrade outdated again which is very annoying. Actually I believe this is the reason why gentoo introduced the per package configuration in the first place.

I don't understand these remarks. MacPorts preserves your variant selections across upgrades. pymol does require that tk is installed without the quartz variant, so to fix that, you run sudo port install tk -quartz * once and you're done. MacPorts will remember that for any future upgrades of tk.

(*When this ticket was filed, +quartz was a default variant of tk. That was changed a few years ago and now +x11 is a default variant of tk.)

MacPorts didn't used to preserve deselected variants across upgrades but that was fixed in MacPorts 1.9.0 which had already been out for over a year when this ticket was filed.

For this specific case, it would be a better investment of time to fix pymol so that it does not have the tk/tcl variant restrictions that it has.