[gentoo-dev] Re: Implicit system dependency

[Michael Palimaka]

On 14/11/14 15:01, Rich Freeman wrote:
> 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.

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 :-)