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

[Ralf Mardorf]

> On 25 Mar 2017, at 16:31, Tinu Weber <takeya at bluewin.ch> wrote:
> 
> Now, is that no longer Arch Linux? I would say Yes. But with the current
> policy, it appears that No. Not because I'm running unsupported
> software, but because I just got rid of a few things that I don't need.
> Same goes for my laptop setup (although for a smaller set of missing
> packages there). Or my little test container, where I don't need the
> kernel, for instance.

Some of the mentioned packages you don't need, are packages I don't need, too.
IMO something like "linux" and "dhcpd" are for very good reasons part of " base". Fortunately I'm using "dhcpd", but Instead of "linux" I build my own RT patched kernels.
So I would welcome, if linux-headers would be part of "base" as well.  "linux-headers" are dependency of "virtualbox". Wouldn't it be good, if we simply could remove  "linux-headers" after "base" was installed, instead of the need to fulfill "virtualbox" dependencies in one way or the other?  What I try to point out is, that "base" not necessarily does cause "bloat", because we are free to remove packages, but "base" could be helpful to avoid being forced to install unwanted packages. Yes, Arch is still Arch without "dhcpd", it anyway belongs to "base". We could turn a blind eye, we aren't an orthodox religion.

> I do not oppose the idea of having a group of packages that are
> *recommended* to be installed - people who don't quite know what they
> need can just install that group and assume that they will probably not
> run into too much trouble. But people shouldn't be *forced* to install
> those packages (or find themselves in the "not supported here!" zone).

If "nano" is installed, the install doesn't become bloated, but it's a kind of standard and some users expect nano to do the very first steps. If you remove nano your Arch still is supported. If "systemd-sysvcombat" isn't installed, then you can't expect that your Arch is supported. The developers perhaps make decisions without that much discussion, just because it's ridiculous to waste time to decide if one or the other package belongs or doesn't belong to "base". Expecting that "base" is installed, is good. It's not really a problem if base contains a few "disputed" packages, this doesn't make a default install bloated.

> I find a little irony in the fact that you use to pactree/pacman to show
> that nothing depends on nano, when the issue here is exactly that
> pactree/pacman becomes unreliable for packages in base.

:D

You are right! I made a mistake, but I guess the point I made should be still clear.

> Of course, nano is tiny, and there is no harm in keeping it around. But
> together with all the other packages we don't need, it starts feeling
> like clutter. Especially if I have to mentally filter out those packages
> from the output of `checkupdates` before I decide whether I want to run
> that update, or leave it because it only affects packages I don't use.

I don't have the same "feelings" regarding "clutter" caused by packages from "base" I don't need. I get this feeling for a higher level of software, so I compile some software myself or install empty dummy packages to fulfill dependencies. Should Arch developers really be forced to think that much about what belongs to "base" and what not? "base" isn't bloated and a selection off valid packages, even if one or the other package is disputed. I agree that much likely just less people need reiser tools, but OTOH we could remove the reiser tools and packages with a dependency to reiser tools don't need to mention them as a dependency, so we aren't forced to install dummy packages or build the packages ourself without the reiser tools dependency ;).

Regards,
Ralf