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.