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

[Ralf Mardorf]

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 at archlinux ~]$ pacman -Qo /usr/bin/basename 
/usr/bin/basename is owned by coreutils 8.26-1
[rocketmouse at archlinux ~]$ pactree -r coreutils | grep bash
[rocketmouse at 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 at 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