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