Re: [gentoo-dev] Re: Implicit system dependency

[Rich Freeman]

On Thu, Nov 13, 2014 at 9:38 PM, Michael Palimaka <kensington@g.o> 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