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

[Xyne]

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