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

[Xyne]

Allan McRae wrote:

> I think we have established the Transitive closure is impractical, so 
> lets exclude that.
> 
> The "current Arch way" has the advantage of speed in dependency 
> resolution if B is installed, but suffers from potential breakage if C 
> removes D from its dependency list.
> 
> How common would such breakage be?  I'd argue that it would be fairly 
> rare as software tends to gather more dependencies and not less.  Also, 
> since spreading the word about building in chroots, bug reports about 
> missing dependencies are much rarer, again indicating it is not a common 
> occurrance.  Given we are competent Linux users around here and can deal 
> with what would be minor breakage, I'd lean towards taking the speed 
> advantage and fix the rare bugs as they occur.
> 
> 
> So getting back to the original point of this thread...  if D is glibc, 
> for most packages there is zero chance of breakage by not listing it as 
> a dep of A because it will be on all systems.  So there is only advantages!
> 
> Of course, some low level packages in [core] rely on having glibc 
> installed before them for correct system installation and so glibc 
> should be listed in their depends list.  So no rule about the inclusion 
> or not of glibc in the depends list can really be made...  it is up to 
> the packager to know what they are packaging and make their own decisions.
> 
> 
> So my conclusion is to only list glibc as a dependency if you are 
> packaging low level stuff that will be installed during the initial 
> installation of a system.  Otherwise, leave it out.
> 
> Allan

I consider the correctness of metadata to be an advantage in itself. Relying on
implicit rules is ugly and will inevitably cause problems. I've actually run
into some of those, e.g. when installing pacman|makepkg in a chroot... it
assumes several dependencies (e.g. "file"). There's a dusty bug-report about
that on Flyspray.

I've always though that even implicitly depending on base-devel is just lazy.
It actually goes against the Arch way in that it expects users to dump several
packages on their system that they may never use in order to satisfy
dependencies that might arise... that's easily falls under the definition of
"bloat", even if it doesn't require significant disk space by modern standards.

How much overhead is there in checking all direct deps explicitly? Does adding a
few pkgnames to the array really make a noticeable difference? I would expect
that it takes considerably more time to track down groups and providers, given
that metadata from the db has to be loaded for those, whereas resolving a dep
will in most cases only require checking for an entry in the db (and resolving
it further if it's not installed, but most operations are upgrade operations and
those usually have their deps already satisfied).




+1 for including it as an explicit dependency.



Regards,
Xyne