On Sat, 25 Mar 2017 06:47:07 +0000, Xyne wrote: >A bash script should depend only on bash.
Hi Xyne, Seems to be better it would depend on coreutilsor do you asume a bash script only depends on bash intern commands and woun't use external commands such as e.g. basename? [rocketmouse@archlinux ~]$ pacman -Qo /usr/bin/basename /usr/bin/basename is owned by coreutils 8.26-1 [rocketmouse@archlinux ~]$ pactree -r coreutils | grep bash [rocketmouse@archlinux ~]$ pactree coreutils | grep bash │ └─bash provides sh │ └─bash provides sh │ └─bash provides sh >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. A user always is allowed to customize the install. On my install are even some hard dependencies missing, but on another software level, not on the base level. The Arch community needs to share some base system. If we wouldn't, we wouldn't need Arch related mailing lists. There must be something in common to call Arch "Arch". >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). Correct. What's wrong with this approach? You safely could remove nano, to free the immens amount of disc space it takes. Others, e.g. Eli seemingly do this. Unlikely a package explicitly will have a hard dependency on nano. [rocketmouse@archlinux ~]$ pactree -r nano nano Just in case a package really should depend on nano, then the user needs to reinstall it. I expect a user who decides to remove packages from "base" to understand what she's doing. There are valid reasons that base does include a few packages, such as nano, even if those are not necessarily required or fit to UNIX standards from the 70s. >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. That's not the point. As already pointed out, the Arch community needs to have something in common. We could customise Arch Linux a lot, but if e.g. everybody of us would use a different init system, we wouldn't share the same distro anymore and can't help each other. And again, it makes sense that Arch provides software that is _quasi_ a sort of a standard by base, e.g. nano. OTOH if somebody really dislikes something like nano that much, a user easily + safely could remove it. OTOH removing coreutils or systemd-sysvcompat (even if you don't need sysvinit backward compatibility) wouldn't be very smart. Assuming that an Arch install is build upon a set of basic packages, e.g. systemd-sysvcompat is a good approach, not to reduce typing PKGBUILD dependencies, but to ensure that different Arch Linux installs have something in common. Regards, Ralf