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

[Allan McRae]

On 22/01/11 00:43, Xyne wrote:
> 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.

Isn't this exactly the issue here?  The original question was whether we 
should include glibc in the dependency list for a package.  I pointed 
out a case where including glibc in the depends is critical and a case 
where it is a waste of time, indicating there is no one answer to such a 
question.


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

The answer is no.  "readelf -d" only lists directly linked libraries. 
"ldd" gives the entire link chain.


>> 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.

Idealistically, I might even agree with you.  I just think it is not a 
practical thing to do.  And if we move away from just using binary 
libraries as examples, we can find situation where we can make 
guarantees that a dep of a dep will never be removed.

e.g. I have a some perl software that depends on the perl-foo module. 
If we list all dependencies, I would need to list perl and perl-foo. 
But I can guarantee that perl-foo will always depend on perl, so do I 
really need to list perl as a dep?

> 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.*

Again, I think this is too idealistic.  Our current dependency checking 
tool (namcap) has a lot of issues determining the dependencies of a 
package and it is not be refined much at all...

Allan