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

[Xyne]

On 2017-03-23 09:32 -0400
Eli Schwartz via aur-general wrote:

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

Obviously there has to be a system for a package to be installed on and that
system has a finite number of necessary components that will always be present.
If that's what the base group was, then we would likely be in agreement. As it
stands now, a python module, for example, doesn't need nano, systemd, lvm, tar,
vi, etc.

As for valid use-cases, minimal chroots are one. I'm not going to argue for the
others.

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

glibc seems to be your go-to example but it's not the best example. Loads of
packages depend on it already. Should all of those deps be removed? Should you
really be able to uninstall glibc without pacman complaining about broken deps?

A binary that links against glibc should directly depend on it imo. A bash
script should depend only on bash. Same for other scripts and their respective
interpreters.

The remarks about a working system are conflating two distinct concepts. A
system is needed to run code in the first place. That's a given. Once you get
that code running, it in turn directly runs other code or uses other data.
That is a dependency in the sense of package management. The infrastructure for
running the code is not. That's a meta-dependency. If you want to compare the
two, you may as well throw in hardware specs. Those are also equally necessary
but it's a different type of dependency.


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

Agreed.


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

Pacstrap *should* install everything necessary for a chrootable system (minus
whatever mountbinds the host system has do provide). A bootable system is a
different matter. In the chroot case, you want to run foo (foo is the primary
target). In the bootable case, you want to boot a system, and then run foo (so
the system is the primary target).


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

From the current "Arch Linux" wiki page:

> The default installation is a minimal base system, configured by the user to only add what is purposely required.

It is still up to the user to decide which packages to install even if base is
recommended. If you don't use nano or lvm, there is no need to install those
packages, for example. Getting rid of systemd is far more complex due to its
centrality in the package ecosystem, but there are nevertheless plenty of
packages that happily run without systemd and thus systemd is not a direct
dependency.


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

The whole discussion is about whether or not the base group should be installed
by default or at least assumed to be installed. If packages will not work
because dependency resolution fails in the absence of unspecified base
packages, then you are essentially forcing the user to install the full base
group (or manually resolve deps after noticing that a package doesn't work).


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

Sure. Pacman could assume that the full base group is installed. It could
even assume that all of core is installed. It doesn't need to assume that
though. I think it's better if it makes no assumptions as we can easily provide
the information explicitly.

If you can identify a minimal group of packages that are required for any given
package to run in all use cases, then that would be a reasonable assumption
that could be omitted from explicit deps.



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

Yep. I think makedeps should be explicit too and I stated so in a previous
reply. I'm not arguing for that here though. Also, base-devel is a little
different in that it is assumed for building packages, not running them. You
don't need to keep it on your system to ensure dependency resolution when
installing packages.


>TIL, Arch Linux is bloated and lazy. o_O

If you require users to install packages that they will never use and
technically don't require in order to be able to use the system normally, then
that is bloat. If you do so because you don't want to type a few extra words,
then that is indeed lazy.

No need for sarcasm btw.