On 2/5/19 4:31 PM, Gaetan Bisson via arch-dev-public wrote:
Bruno,
We all seem to agree that [base] plays no satisfactory role in its current state, so I think Allan definitely has a point: let us first turn [base] into something useful, and only then wonder if we need something more.
[2019-02-05 14:38:26 +0100] Bruno Pagani via arch-dev-public:
Le 05/02/2019 à 12:54, Allan McRae a écrit :
If someone knows they want to set up logical volumes and drive encryption, then they know enough to install lvm and cryptsetup. Same with jfsutils, xfsutils. So I don't think they should be in the base group (e.g. I would not call jfsutils a standard tool).
Maybe. As I said in my answer to Bartłomiej, I don’t know if beginners know enough things to install what they need beyond the minimum system, or if they just read the wiki about doing this or that, which might assume they have the current base group installed.
Then the wiki should just be updated to say: "first, install jfsutils." It's up to the wiki to document the project, not up to the project to follow the wiki's rule.
If we remove the excess from base, then we are down to a very small difference between that and archlinux-system. Only e2fsprogs, man, and an editor different?
So I see the proposed archlinux-system group being essentially what base should be.
That is because you see base as the minimal system.
So I’ll turn this differently: do you have objections against having, outside of the minimal meta-package described in our proposal, a packages group of “relatively standard” tools, that is purposed at beginner wanting to have only one simple pacstrap command to issue in order to get started?
Yes because those two things seem the same to me. Or at any rate their difference is too small to be worth the distinction. Perhaps I'm not understanding what exact roles you envision for [base] and [minimal- system]; it would help to know exactly what packages you would put in the former and not the latter. Allan suggested e2fsprogs, man, and vim. We can certainly agree that three is too few to warrant creating two distinct groups.
less, because I cannot imagine an interactive console without a pager texinfo, for the same reason one would want man-db. (Also, GNU tools tend to have terrible manpages, so you kind of need texinfo even if you just pipe it to less). man-pages, to get a good starting collection of things to use man-db to read (section 3, 4, 5, 7, and 1p will be quite bare otherwise). systemd-sysvcompat to simplify the kernel command line. s-nail, because some people apparently assume a complete system should include the "mail" binary for completeness' sake. dhcpcd and netctl, commonly used for networking by people who don't understand the glories of NetworkManager. (Also the archiso.) which, because too many things on the internet recommend using it to find out whether/where a program is installed, and muscle memory therefore means people will instinctively try that instead of using command -v/type -a ... In fact, most of the base group, with the grievous exception of: - jfsutils/reiserfsprogs/xfsprogs which assume quite odd things about non-default and usually exotic filesystems, and - lvm2/mdadm which offend my soul due to things like https://bugs.archlinux.org/task/61040 screwing up the system even for people who will never touch lvm are reasonable things to suggest to people by default. It is simply that there is also a lot of those, which people rightly don't want to be *forced* to install. I don't want or use which, nano, vi, or mailx for example. Does that mean most people won't? I venture to say more users than not, will feel grateful for a group that recommends at least the first three to them. It is just that the utility of the base group as a recommendation is hindered by lack of something to define the minimum. ... We already have more than a few sets of packages that are defined by both a group and a metapackage for user convenience, e.g. https://wiki.archlinux.org/index.php/KDE#Installation So if it was really super inefficient to have both base and base-system then we could clean up lots of other stuff in the repos too... ... On a slightly less serious note, it's almost amusing to see base being considered for the scrapyard at all. Given how impossible it was to even get jfsutils and reiserfsprogs removed from base, even though, one of the only things that previous discussions ever had so much as two people agree on is how useless these are, I was sort of expecting base to continue to exist merely in order to exist. Those two are so not base that I'm genuinely bewildered why they are or would or could be in either base or base-system. At least xfs is common due to being both well-known and stable. -- Eli Schwartz Bug Wrangler and Trusted User