[aur-general] [arch-general] Please settle 'base' in 'depends' for all

[Xyne]

Allan McRae wrote:

> I pointed out that hard rules are not good.   e.g. coreutils should (and 
> does) depend on glibc as it is not guaranteed that glibc is installed at 
> the time when you first install coreutils (which is likely the initial 
> install).   But there is no point putting glibc in the depends list for 
> (e.g.) openoffice-base as it will be installed by that stage.

That's irrelevant to this discussion because it's a bootstrapping issue. I
don't know how cyclical dependencies and other initialization problems should
be handled, but they constitute a special case that should be detected and
dealt with separately.



> Two points to consider:
> 1) How much more complicated would it be to list all dependencies?
> 
>  > readelf -d $(pacman -Qql openoffice-base) 2>/dev/null | grep NEEDED | 
> sort | uniq | wc -l
> 150
> 
> That is a lot of libraries... although some will be in the same package 
> so that is an upper estimate.   But that is only libraries and the 
> complete dep list will be longer than that.

I agree that is a lot. Of course we can't reasonably expect a packager to
manually enter 150 libraries into a PKGBUILD, but are all of those direct
dependencies? Maybe this is a silly question due to my ignorance of linking,
but are any of those libraries linked via other packages? For example, if bar
provides code that links to baz, and foo builds against bar, would baz turn up
in the readelf output for foo? If the answer is yes, then baz would not be a
dep of foo, even if foo links to it, because the linking was established
"indirectly", i.e. bar could have used something else.

Of course, in that case, baz would be a strict runtime dependency (unless
sodeps could resolve this, but again, my understanding here is limited), but
from a graph-theory pov, foo would only depend on bar. Such a situation would
only require a rebuild, just as it would now (i.e. if baz were replaced by
something else).



> 2) It is worth the effort?   We have very few bug reports about missing 
> dependencies and most (all?) of those fall into the category of missed 
> soname bumps or due to people not building in chroots.  I.e. these are 
> because of poor packaging and not because we make assumptions about what 
> packages are installed or the dependencies of dependencies.
> 
> 
> So I see making a change to the current approach as making things (1) 
> more complicated for (2) no real benefit.

The answer depends on the answer to my previous question. The current system
does indeed work, but it provides no strict guarantees. I think good practice
in general is to make something that is critical as reliable and future-proof
as possible, and I see that as a true benefit. It's like wanting to agree upon
an open specification instead of just letting everyone do it their way and hope
for a triumph of common sense.

Admittedly, I doubt it would be a problem in the future and I'm discussing this
idealistically.

As for complication, even if there were a large number of deps to consider,
there would likely be ways to generate at least a tentative list using simple
tools. It could then be refined through feedback.*