On Thu, Nov 13, 2014 at 9:38 PM, Michael Palimaka <kensing...@gentoo.org> wrote: > On 14/11/14 11:06, Rich Freeman wrote: >> >> Well, the idea would be to maintain the virtual INSTEAD of @system, or >> have @system just pull in the virtual and make some arch-specific >> additions. > > Will that work? Some profiles remove packages from the base @system and > replace it with their own implementations (eg. BSD).
Maybe. The thing is that a package either depends on something or it doesn't. If it really does depend on something, then the fact that it isn't available on BSD/etc isn't going to magically make the package work. We just loosely define system dependencies in a way that makes them work 98% of the time, basically accepting that things are going to break and we get away with it because few of our users actually run on BSD/etc. If it is just a matter of preference then a profile could install an alternative package that is in a virtual. However, this won't work if everybody still uses some convenience virtual that pulls in bash/etc and the BSD folks don't want to install bash unnecessarily. The only perfect solution is explicit dependencies across the board. If we want to be lazy and not have to list 50 deps for hello world, then the package manager isn't going to know whether hello world actually works on every arch/profile/etc. Maybe the better solution is some kind of automation around (R)DEPEND. In any case, I agree that it is a bit beyond the original scope of this. > Maybe some dependencies (within reason) should always be listed, for > example when there's linkage eg. to libbzip2 or liblzma. That would make > it easy to find consumers eg. if an alternate implementation appeared, > and already appears to be a common practice. The problem is that if it isn't 100% then it isn't all that great a solution. It also isn't really necessary unless you want to remove a package from the system set. If an alternative implementation appears, then you create a virtual, place that virtual in the system set, and all the packages in the tree remain happy to use whatever implementation the user has installed without the risk of it getting depcleaned. In the past when we've considered removing a package from @system there is usually a thread on -dev, and if there is a general sense that we want to move forward then the announcement goes out for everybody to check their packages and add an explicit dependency if needed (often with tinderbox runs and the like). Then after a delay the package is removed from @system and maintainers get to deal with anything they missed. I don't have a problem with devs listing dependencies anytime they're real and they feel it makes sense to do so. I wouldn't make a push to have them go out of their way to do it for any particular package unless we are actively looking to remove it from @system, or there is some other driver. Slot operator deps would be the one case where I would try to push on maintainers to list deps. And I do apologize for piling on a bit - trying to get rid of @system has been one of my soap box issues for a while. It really seems like an ugly, if practical, solution. -- Rich
