[aur-general] Should "base" packages be listed as dependencies?

[Xyne]

>Well, it also means, for example, that you don't have to keep listing
>things like bash and glibc in literally hundreds of PKGBUILDs.

I understand that argument, but it is framed as if people are writing hundreds
of PKGBUILDs at once and the added deps are overly tedious to include, when in
fact they are written one at a time and it's only a few extra words (at most)
alongside however many constitute the PKGBUILD. For makedeps, most of these are
not even needed because they are indirect deps of base-devel. All runtime deps
should be resolved though, either directly or indirectly.

The only valid technical argument would be if the overhead of the dependency
checks is prohibitive. I expect that it is negligible (but admittedly haven't
checked) and it is worth technical correctness.

It's like quoting path variables in PKGBUILDs: most people build in "sane"
paths but it's still poor form to omit the quotes and assume that no one builds
on paths with spaces. The arguments "but I don't want to type more quotes" and
"but all those quotes across all the PKGBUILDs take so many bytes" are rightly
rejected.



>> There is no "base installation" of Arch Linux. That's one of the defining
>> features of this distro. Forcing some people to install bloat and cruft (or
>> play dependency spelunker) to save a few keystrokes in a PKGBUILD is just
>> wrong.  
>
>There absolutely is a base installation. Unless you are suggesting e.g.
>systemd-less systems constitute a supported Arch Linux installation?

This isn't about what is officially "supported". This is about how one tool
performs a task. Arch provides flexibility. There are custom kernels and
alternative init systems in the AUR for example. If you customize your system
then you are expected to deal with problems arising from that customization
yourself, but core functionality of the package manager should not rely on all
users installing essentially the same base system. We are talking about
dependency resolution here. Pacman is not tied to systemd or whatever else you
consider to be part of a "base installation". It shouldn't even matter what
other packages the user is using as long as pacman's own deps are satisfied.
For dependency resolution, Pacman's job is to determine what the user wants to
install and then figure out what else the user needs to install it. All it
needs to do that is the correct metadata, which is just a few extra words in
some text files. That is better than implicit assumptions that may silently
change in the future.




>I thought that was the point of suggesting that minimalist build chroots
>potentially require base as well...

A chroot that requires all of the base group is not minimal, it's bloated.


It's like a lazy fruit vendor dumping apples, oranges, bananas, etc. into one
giant bin because he can't be bothered to put them in separate bins (even
though he has them, and it would be simple to do), then forcing customers who
only want apples to buy big boxes of mixed fruit so that they can sort out the
apples themselves and throw the rest of the fruit away (after paying for it).


Regards,
Xyne