[gentoo-dev] Re: Implicit system dependency

[Michael Palimaka]

On 14/11/14 11:06, Rich Freeman wrote:
> On Thu, Nov 13, 2014 at 10:07 AM, Michael Palimaka
> <kensington@g.o> wrote:
>>
>> Ditching implicit dependencies is an interesting idea but not practical.
>> Nobody wants to the laundry list, and there's little benefit in
>> maintaining a virtual/system clone of @system.
>>
>
> 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).

>
> As far as benefits go, they include:
> 1.  No need to have multiple ways of grouping packages.
> 2.  You can more than one virtual, so that you could just pull in the
> super-lazy equivalent to @system, or maybe you just pull in POSIX+bash
> and C++ or something like that.
> 3.  You can split up that virtual so that convenience packages like
> ssh aren't in the same virtual as widespread dependencies like
> bash/zlib/glibc/gcc/etc.  There is no reason that you can't build
> openssh in parallel, but right now you can't because we lump it in
> with glibc.
> 4.  You can choose when to use the virtual at all, versus explicitly
> naming all dependencies.
>
> For 99% of packages it would be the same.  We could even have that
> dependency added automatically if something isn't done in the ebuild
> to disable it, which would make ebuilds work the same as they do now.
> However, for the packages that are actually in @system we could list
> explicit dependencies and then portage would actually be able to
> handle some things automatically.  Also, by using virtuals that are
> the same across all archs, we have a bit more consistency.

Definitely interesting ideas, but I think it's beyond the scope of
what's trying to be addressed here. Solving bug #393445 would also go a
long way to sorting out core-system vs. want-to-have packages.

> Policy-wise, though, the status quo isn't that bad.  You never have to
> list dependencies that are in @system, full stop.  You can list a
> dependency that is in @system anytime you want to, full stop.
>
> That is, it is never right or wrong to list an unversioned dependency
> that is in @system.  Sometimes doing one or the other is advantageous
> (such as when you have a versioned dependency, or a virtual is in
> @system but you need a specific implementation, or you want to use a
> slot-op dep).  I'm fine with examples, but they shouldn't be firm
> rules, just helpful guidelines.

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.

Perhaps instead of creating a whitelist, we could just update the text a
bit:

All packages have an implicit compile-time and runtime dependency upon
the entire system target. For toolchain packages part of the system
target (such as gcc, libc, binutils and so on) it is not necessary, nor
advisable, to specify dependencies, except where specific versions or
packages (for example, glibc over uclibc) are required.

For other non-toolchain packages part of the system target (such as
bzip2 or wget) it is optional to specify a dependency. Consideration
should be given to packages that don't appear in system targets in other
profiles or might be removed in the future. Where package links to
package in the system target (such as libbz2) it is recommended to
specify a dependency.