Please add FEATURES, ARCH and USERLAND to USE_EXPAND so that we can sanely handle maketest-specific deps, collision-protect-specific code without nasty hasq hacks, *bsd-specific deps and so on.
ohhh yes pretty please.
Adding this to USE_EXPAND just somehow seems wrong. perhaps FEATURES_EXPAND, USERLAND_EXPAND, ARCH_EXPAND? USE_EXPAND somehow logically implies the env variable USE=.
No no. USE_EXPAND means it gets expanded *into* USE.
what Aaron said =)
Hopefully not too OT, but how about further implementation of glep 22? With the latest darwin profiles, we are slowly moving towards the exact situation the author described, the jumbling of arch-kernel-userland-libc. Shortly(couple months?) as wacky as it may sound, such configurations will exist: {x86,ppc,ppc64}-{darwin,od,macos}-{bsd,darwin,gnu}-darwin obviously no x86-macos, and the darwin libc remains constant... I would guess *bsd would have similar configurations available at some point as well. So all that being said, was the possibility of doing things like: use *-darwin-gnu && foo in ebuilds ever intended? http://www.gentoo.org/proj/en/glep/glep-0022.html
what more do you really need for GLEP 22 ? the KEYWORD explosion feature is in portage now
*** Bug 78898 has been marked as a duplicate of this bug. ***
And now we find a situation where KERNEL in this would be nice too (enabling linux-kernel-specific features; can't use USERLAND since people are starting to do GNU/kFreeBSD). Any word on whether people want to implement this?
Personally I don't like FEATURES in that list, the others I don't mind.
Ok, if FEATURES is removed, is there an elegant way of handling maketest-specific dependencies?
Following spb's comment #8, a KERNEL variable (use-expanded) could be useful for non-linux systems (g/fbsd, g/kfbsd, g/osx, g/darwin, ......). See for example dnotify on kde-base/kdelibs and smbmount in net-fs/samba.
And we now find ourselves wanting to switch stuff based on the libc being used. So, that makes the list ARCH, KERNEL, USERLAND, LIBC please. :)
I think just FEATURES is missing now, hoping LIBC is not making ebuild upsets.
I think I can see why FEATURES is needed ... someone has something to say about this?
FEATURES includes collision-protect. Systems that are -collision-protect often have updated versions of dependencies which makes certain patches we use for ppc-macos collision-protect systems uneeded and more exactly non-working. I could also see instances with future pathspec implementations where this might be desired. For instance, if FEATURES contains some indicator of where portage is installing to, the behavior of things like vim plugins might need to depend on that installation target. As far as ppc-macos is concerned at this point, our concern is with differentiating between collision-protect and non-collision-protect systems. If FEATURES in USE_EXPAND is undesirable, being able to handle deps and patches based on profile would also work, although it would not address the second point made above.
FEATURES are not supposed to have an effect on the package itself, just how portage handles the package. Packages behaving differently on certain FEATURES settings are considered broken by me. The only valid point so far that I've seen is with additional deps for src_test(), and that will probably be handled with just USE=test or another similar workaround. For the same reasons the prefix stuff won't be a FEATURES setting. As for the "depending on profile" idea, that has a completely different set of issues.
USE="test" is still a dirth hack, that's the problem. One should suppose that adding FEATURES="maketest" is enough to have it working.
I meant USE=test being added by portage automatically if test is in FEATURES (maketest is obsolete), similar to ARCH (why was there a need to add that to USE_EXPAND btw?)
test/maketest whatever it's called it's that the same.. yep probably have it "forced" by portage should be good, but in that case better not have it in IUSE at all, and avoid users pull it from outside. About ARCH.. I think the idea was that ARCH should be just the first part of the keyword (so for example x86-fbsd $ARCH == x86) but atm it's not like so and so ARCH doesn't need to be use-expanded.
(In reply to comment #16) > FEATURES are not supposed to have an effect on the package itself, just how > portage handles the package. Packages behaving differently on certain FEATURES > settings are considered broken by me. The only valid point so far that I've seen > is with additional deps for src_test(), and that will probably be handled with > just USE=test or another similar workaround. Xorg's another exception to this. It has custom stripping code so it checks for nostrip.
features="selinux" is another of the special cases (look into the use flag selinux). So... strip, selinux, and test. What valid examples are their for other features being used as conditionals in *depend? Specifically, example of why it would be useful/warranted for collision-protect?
Not sure about collision-protect: the way it's used in Gentoo/OSX is almost completely different from the way it's used for example in Gentoo/FreeBSD: in the first case is used to avoid overwriting system files, in the latter it's used to see which packages aren't needed or must be removed from freebsd's base system).
What was decided about adding test to the USE=test for test deps?
I don't like the way to convert everything into use flags. Imho ARCH, mmx etc. should not be use flags, but go in a detailed profile tree, so users just have to switch their profile symlink to crosscompile.
Carlo -- I don't think you're understanding this bug.
Ciaran, I think I do. I just want to get away from use flags for processor specifics like mmx or altivec at all. And I don't think that has something to do with maketest.
in order to 'get away' from processor-specific USE-flags, we need a target to 'go to' ... i dont believe ive ever seen/heard a proposal that didnt involve USE flags
Carlo -- this bug, as it stands, is not related to CPU flags. If you're wanting to move CPU flag stuff into its own expanded var, the portage side of things is already there.
.
(In reply to comment #23) > What was decided about adding test to the USE=test for test deps? Ditto. perl herd packages have dependencies for testing that aren't required for either building or installing. Is there any progress on this particular iota? :)
Bug 122382 for the specific FEATURES="test" issue. If there are any other FEATURES="..." issues, please open individual bugs for them.
Hi What's going on with this bug? There's been recent discussion of the same issue on -dev ( http://comments.gmane.org/gmane.linux.gentoo.devel/44019 ) and I can't work out why it's marked fixed. Also, it's marked as dependent on 122382 which is actually a dupe of 69021, which itself hasn't been resolved. I don't have any solutions, sorry, I'm just trying to flag the issue in an office admin sort of way. Cheers, Steve.
(In reply to comment #32) > Hi > > What's going on with this bug? There's been recent discussion of the same > issue on -dev ( http://comments.gmane.org/gmane.linux.gentoo.devel/44019 ) and > I can't work out why it's marked fixed. Also, it's marked as dependent on > 122382 which is actually a dupe of 69021, which itself hasn't been resolved. > > I don't have any solutions, sorry, I'm just trying to flag the issue in an > office admin sort of way. > > Cheers, > Steve. > Because USERLAND is USE_EXPANDED, ARCH is already EXPANDED into USE in a weird ass method, and FEATURES will be in USE over my dead body :)
