There are cases where USE flags change the ABI of a package (at the moment in base-system there is an issue where the "tinfo" USE flag changes the ABI of ncurses). It would be useful to be able to make the state of a particular flag be part of the subslot for a package. I would suggest a syntax like this: SLOT="0/6[foo]" This would make the state of the "foo" USE flag a part of the subslot for that package, so changing the state of the flag would trigger rebuilds for all packages with a subslot dependency on the package defining the subslot.
Do you think of something what happened to wxGTK for example: --- $ eshowkw x11-libs/wxGTK Keywords for x11-libs/wxGTK: | a | | | m | | | d x | | | 6 8 | | | 4 6 | u | | a a a p s | | | n | | l m r i p h m s p f m f | e u s | r | p d a m a p c x p 6 3 a b i b | a s l | e | h 6 r 6 6 p 6 8 p 8 9 s r s p s | p e o | p | a 4 m 4 4 c 4 6 a k 0 h c d s d | i d t | o --------------+---------------------------------+--------------+------- 3.0.3 | + + + ~ + + + + + o o ~ + o ~ ~ | 6 # 3.0 | gentoo --------------+---------------------------------+--------------+------- 3.0.3-r300 | ~ + ~ o ~ + + + ~ o o ~ + o ~ ~ | 6 o 3.0-gtk3 | gentoo --------------+---------------------------------+--------------+------- [I]3.0.4 | + + + ~ + + + + + o o ~ + o ~ ~ | 6 o 3.0 | gentoo 3.0.4-r1 | ~ ~ ~ ~ ~ ~ ~ ~ ~ o o ~ ~ o ~ ~ | 6 # | gentoo --------------+---------------------------------+--------------+------- 3.0.4-r300 | ~ + ~ o ~ + + + ~ o o ~ + o ~ ~ | 6 o 3.0-gtk3 | gentoo 3.0.4-r301 | ~ ~ ~ o ~ ~ ~ ~ ~ o o ~ ~ o ~ ~ | 6 o | gentoo
1. Should this really be part of the dependency and not of the dependee? I dare say there will be packages that are unaffected by the presence of tinfo, or any similar ABI-defining flag. 2. I'm strongly against adding anything else to SLOT. Adding subslots there was an API catastrophe enough, with 'slot' suddenly starting to mean either 'just the slot' or 'slot+subslot', depending on the context. This should really be stored separately. 3. All those reverse dependencies are horrible but I guess we're not going to lose much, given that subslots already force the lookup.
It might be more systematic to add this as another type of USE dependency in the depending package, with a meaning like "any setting of the flag is fine, but reinstall this package when the flag changes in the dependency". Unfortunately, the "cat/foo[bar=]" syntax is already taken.
Make it 'bar@', with @ resembling shape of a binder ;-P.
(In reply to Michał Górny from comment #4) > Make it 'bar@', with @ resembling shape of a binder ;-P. Not possible, because @ is a legal character in USE flag names: "A USE flag name may contain any of the characters [A-Za-z0-9+_@-]. It must begin with an alphanumeric character."
https://bugs.gentoo.org/677292 is another example of ABI dependency on gtk+[wayland]. Once gtk+'s USE=wayland is flipped off many revdeps need a rebuild.
I want to point out the relationship between net-im/telegram-desktop and media-libs/tg_owt would also benefit from a solution like this. Currently this is being solved by propagating the USE flags to the (singular) dependant: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5f02a6813a0fce67287cc49bf1ddcd2712da2389 But of course, this would quickly become unmanageable for bigger dependency trees.
This requires ebuild writers to figure out which USE flags break ABI. Can it not be made more automatic?
(In reply to Ulrich Müller from comment #3) > It might be more systematic to add this as another type of USE dependency in > the depending package, with a meaning like "any setting of the flag is fine, > but reinstall this package when the flag changes in the dependency". > > Unfortunately, the "cat/foo[bar=]" syntax is already taken. The meaning of = also implies direct equality, which is indeed how it is currently used. There's two cases here where the USE flag of the dependency changing implies reinstallation of revdeps: - if the USE flag was originally set, and becomes unset, then the revdeps need to be rebuilt - if the USE flag was originally unset, but becomes set, then the revdeps need to be rebuilt Also case 3: - if the USE flag changes in either direction, then the revdeps need to be rebuilt. But case 3 is exactly what [bar=] currently means. What we want is to handle the other two cases. In particular, case 1 is what we care about for at least this: (In reply to Sergei Trofimovich (RETIRED) from comment #6) > https://bugs.gentoo.org/677292 is another example of ABI dependency on > gtk+[wayland]. Once gtk+'s USE=wayland is flipped off many revdeps need a > rebuild. It's not actually an ABI dependency, by the way. It's an automagic dependency. gtk+ provides extra symbols with USE=wayland, and many projects *detect* whether to build against that by checking... whether the symbols exist, rather than checking if a build option was passed to build against those symbols. So we don't care if the symbols/dependency doesn't originally exist, but gets rebuilt to exist -- previously built packages automagically detect the absence of the feature and don't include that feature. We only need this one way. Proposed spelling: gtk+[wayland:?] Like a slot dependency, it binds : to whatever version was installed at the time of building. Like a USE dependency, it binds ? to the state of the installed version only in the positive case, not the negative case.
