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

[Eli Schwartz]

On 03/23/2017 02:29 AM, Xyne wrote:
>> 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.

It is not poor form, it is outright wrong.

BECAUSE PATHS WITH SPACES ARE A VALID USE-CASE! The only reason I don't
feel comfortable using such build paths purely to show it can be done...
is because AUR maintainers are by and large idiots who upload
irresponsible garbage that breaks all the time and has missing
dependencies of *all* sorts, among other numerous common problems when
sifting through huge mounds of absolutely anything authored by
absolutely anyone. :p

And a system that does not have glibc installed is not a valid use-case.
A system without bash is not a valid use-case. A system without systemd
is not a valid use-case, regardless of how many completely-unsupported
people kludge it together with AUR packages (which also are unsupported).

I don't have actual numbers for the dependency checking time... but it
is surely nonzero, and I see no reason to go out of my way to add them
purely for the sake of slowing down pacman's depchecks to whatever
degree, adding PKGBUILD code churn and decreasing clarity by cluttering
it with obvious no-brainers, given that the result is still lacking in
technical correctness, since *technically*, a binary that only links to
glibc still needs a lot of other stuff like a working system running a
linux kernel to run.

Redefining dependencies as shared library linkages would make this a
more compelling argument.

...

Really, if you want technical correctness, then I expect to be able to
pacstrap any single package into an empty partition/directory and have
pacman resolve dependencies to a sufficient degree to result in a
bootable/chrootable minimal installation in which that package functions
as expected.

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

No, just core functionality of, you know the system. Which explicitly
refuses to support the alternative init systems, with undertones of
such-AUR-packages-may-be-crazy. Arch happily compiles runtime
dependencies of systemd into everything, serenely unconcerned about the
trouble this causes the poor saps who try purging systemd.

Arch is *not* about choice or flexibility, not when it comes to the base
system itself. This is a rather emphatic aspect of the Arch Way. After
several complaints from users about systemd specifically, this *had* to
be emphatically clarified.

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

Right... I never suggested that pacman itself enforce a base
installation and I have no idea how you think I would go about doing
that anyway.

People using pacman as a package manager for, say, LFS or MSYS2 are more
than free to provide whatever installation instructions they want, and
make whatever implicit assumptions they like regarding a base
installation, and declare a PKGBUILD style policy suiting those assumptions.

Arch Linux is allowed to have different assumptions than pacman and
makepkg (and base-devel is an example of that).

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

The same logic applies to base-devel, most of which will not be used in
any given build. In fact, there are plenty of PKGBUILDs which use
nothing other than a package() function with calls to mkdir/cp/install.

TIL, Arch Linux is bloated and lazy. o_O

-- 
Eli Schwartz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20170323/d380c5ef/attachment.asc>