On Fri, Sep 25, 2009 at 5:14 PM, Roman Kyrylych wrote:

On Fri, Sep 25, 2009 at 09:39, Allan McRae wrote:

...

Hi all,

FS#12890 (http://bugs.archlinux.org/task/12890) suggests we clean up some crud from the base group. I started a wiki page back in July to look at doing this (http://wiki.archlinux.org/index.php/User:Allan/Base_Cleanup), which should not be too outdated.  The basic premise in my clean up was 1) remove "useless"/unneeded packages 2) remove packages that are in the base group only because they are dependencies of packages in the base group.

An example for #2:  no-one really wants to install libfetch apart from for use by pacman.  Thus libfetch does not need to be part of the base group.

That might be slightly controversial...  but I think it makes sense.  When I install, I look through the package lists and select the packages I need.  I do not directly need libfetch but I do select pacman.   Thus pacman is directly part of my base install but libfetch is only indirectly.

I need opinions here.  Does this make sense to people?  Have my selections been too strict or not strict enough?

It does make sense. I'd go even further and remove cryptsetup, dhcpcd, jfsutils, lvm2, mdadm, pcmciautils, ppp, reiserfsprogs, rp-pppoe, xfsprogs, wpa_supplicant from base group, but leave them in core, so users or installer (for cryptsetup/lvm2/mdadm/*progs can be done automatically) can select them.

That would make [base] the absolute bare minimum to boot the most trivial system. Is that correct? Or is [base] better to be a minimum for a basic/functional system? Pacman says nothing when removing a base package. So base doesn't really mean anything post-install. If it means that wireless and other things become "opt-in" at install time, Thomas is right, the bug tracker will get crushed with 'no wifi, no dhcp, no editor support' type bugs. And we don't really gain anything by removing them from the group. I don't mind if we have a few extras like cryptsetup and dhcpcd in there. So I agree with Allan's list mostly. Though if you're keeping wpa_supplicant there, I'd suggest wireless_tools/iw/crda too. Or remove it.

The filesystem stuff is optional and most users don't need them, so it seems fine to me... but, here's a question. What happens if I install a new XFS system, and fsck is forced on the first reboot for some reason? Isn't xfsprogs required for this? I'm sure it could be installed simply as an extra installer step, however.

Excuse me for not doing a fresh install in a few months, but has the bug been fixed where it always used to fsck first thing after a fresh install because the it thought the last mount was in the future? I vaguely remember this was a timezone or localtime issue, but the last time I did a fresh install this was still happening and thus xfsprogs/jfsutils/etc would be required. Dale

On Fri, Sep 25, 2009 at 18:39, Aaron Griffin wrote:

On Fri, Sep 25, 2009 at 10:28 AM, Dale Blount wrote:

...

Excuse me for not doing a fresh install in a few months, but has the bug been fixed where it always used to fsck first thing after a fresh install because the it thought the last mount was in the future?  I vaguely remember this was a timezone or localtime issue, but the last time I did a fresh install this was still happening and thus xfsprogs/jfsutils/etc would be required.

I actually think this has been fleshed out. If I remember right, Gerhard was behind this. Is this fixed?

It was fixed at least twice as I remember. :-) -- Roman Kyrylych (Роман Кирилич)