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

[Eli Schwartz]

On 03/22/2017 09:07 PM, beest wrote:
> I'm also on the side of explicitly assuming that base is installed (and
> having the wiki and PKGBUILD dox reflect as much), but before that there
> should possibly be a discussion about what actually belongs in base in
> the first place. A few folks are of the mind that a good chunk of the
> group is wholly unnecessary and should be culled.

I will absolutely agree that there are additional packages in base that
shouldn't be. I have brought this point up before a couple times....
Unfortunately, the maintainers of those packages seem to be entirely
happy to leave them as-is, maybe on the assumption borne out in this
thread that no one cares what is in base (except for silly things like
the Installation Guide which no one cares about either, of course).

Bizarrely, other package groups seem to have clearly-defined meanings
which is strongly against the precedent set by the current base group...

fsck/mkfs support for nonstandard filesystems
- xfsprogs
- reiserfsprogs
- jfsutils

Heavily discouraged by pretty much everyone, why on earth would it match
any conceivable definition of "base"...
- netctl :(

Needed for device encryption/LVM/RAID, which not everyone uses
- cryptsetup
- lvm2
- device-mapper
- mdadm

No firm reason for including
- s-nail (an inert mass unless you go out of your way to configure it)
- nano (vi is the standard, and *I* don't even want to include that
  because vim)


I would love for all these to be dropped from base, as I consider them
neither recommended (Scimmia's concept of base IIRC) nor critical (the
intuitive concept of base).

Well, maybe the LVM/encryption stuff could be said to be recommended.
But not critical.

-- 
Eli Schwartz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20170322/25ffc07d/attachment.asc>