On 2017-03-25 16:31 +0100 Tinu Weber wrote: >On Sat, Mar 25, 2017 at 09:19:43 +0100, Ralf Mardorf wrote: >> 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? > >In such a case, yes, the application should state that it depends on >coreutils. I don't see an issue, though, other than "I don't want to >type that".
I was going to say the same thing before I saw Tinu's reply. My example of a bash script was bad given that most bash scripts will indeed depend on coreutils. coreutils is one of the packages that I think should be assumed in a minimal system btw. >> >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". > >I don't think that the Arch community or the OS itself is solely defined >by an arbitrarily selected set of packages that are expected to be >installed. After all, the systems still share the package manager and >the origin of the packages (created and provided by Arch devs) + the >general idea of KISS (e.g. upstream as unpatched as possible, no partial >upgrade support, ...) > >I think some people are mixing up these two things: > >1. Packages that are expected to be there to guarantee a minimally > working system in most situations. >2. Packages that are expected to be there to provide a minimally > comfortable working environment to the user. I agree that people are mixing up two things but I would say that they are 1. Dependency resolution. 2. What constitutes a minimal Arch Linux system. The second is arbitrary. There is no obvious definition, and it doesn't even matter with regard to the first. Explicitly providing the necessary metadata will always work and makes no assumptions. This will benefit all users but forces a few packages to type a few extra words. Assuming (and thereby effectively requiring) that an arbitrary set of packages are installed, even when many of those are unneeded, is a philosophical wart for a minimalist distro that leads to wasted bandwidth and disk space, or broken dependency resolution in some common use-cases. I am actually surprised that there is even an argument for requiring a base system with packages that many users will never need (and the whole "but anyone 'competent' enough to remove some of those packages can manage their own deps manually" is not a valid argument: the distro should not make things more difficult for users who remove unneeded packages). I get that things change, but it's sad to see people pushing Arch in that direction. Minimalism is one of Arch's defining features imo. If packagers do their job (provide package metadata), then pacman can do its job (dep resolution). It's really that simple. If you absolutely want a minimal common group with e.g. glibc, coreutils, linux and whatever else is effectively indispensable, then ok. Even then those packages should be resolved by pacman/makepkg. Regards, Xyne