On 14/11/14 15:01, Rich Freeman wrote: > 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.
I think the proposed text in my previous reply is an improvement on the current text. It certainly doesn't attempt to solve the problem of implicit dependencies 100%, but I don't think that's a good reason to avoid improvement. The new text doesn't change the status quo at all. It just attempts to clarify that: * It's up to the developer if they wish to include a system dependency or not (ie. it's not frowned upon, which was the issue raised in the original bug) * It's recommended (but not required) to depend upon a system dependency if it's linked against (this is already common practice and there seems to be support for requiring it, but I don't want to get too controversial :-)
