[arch-dev-public] Cleaning up base (FS#12890)
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? Allan
On Fri, Sep 25, 2009 at 09:39, Allan McRae <allan@archlinux.org> 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. In addition: remove tzdata from base, it is pulled by glibc anyway. Also removing hdparm/sdparm from core depends on how we solve the issue with Load_Cycle_Count - script in core or page on wiki (or install guide). -- Roman Kyrylych (Роман Кирилич)
On Fri, Sep 25, 2009 at 5:14 PM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
On Fri, Sep 25, 2009 at 09:39, Allan McRae <allan@archlinux.org> 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.
On Fri, Sep 25, 2009 at 2:14 AM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
On Fri, Sep 25, 2009 at 09:39, Allan McRae <allan@archlinux.org> 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.
In addition: remove tzdata from base, it is pulled by glibc anyway.
I agree with this. As long as these things stay in core, its fine. base is just a group anyway. As for the packages Roman suggests, I think we should keep the wireless/networking utilities in there, as we always claim arch is intended to be networked. 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.
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 10:28 AM, Dale Blount <dale@archlinux.org> wrote:
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.
I actually think this has been fleshed out. If I remember right, Gerhard was behind this. Is this fixed?
On Fri, Sep 25, 2009 at 18:39, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Fri, Sep 25, 2009 at 10:28 AM, Dale Blount <dale@archlinux.org> 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 (Роман Кирилич)
participants (5)
-
Aaron Griffin
-
Allan McRae
-
Dale Blount
-
James Rayner
-
Roman Kyrylych