I strongly disagree. wpa_supplicant is pretty huge and unnecessary for many people

I for one have a couple of installations without wireless connections at all..

On 25.04.2015 17:51, Neven Sajko wrote:

I agree that wpa_supplicant probably should not be in base, but it's worth mentioning that base already has many packages not useful to a lot of people - I for example don't have any of these installed: dhcpcd jfsutils reiserfstools xfsprogs cryptsetup lvm2 mdadm nano netctl

+1 for keeping wpa_supplicant out of the base group. And just a general reminder, because it fits into this discussion: "Before complaining about missing (make) dependencies, remember that the base group is assumed to be installed on all Arch Linux systems. The group "base-devel" is assumed to be installed when building with makepkg or when using AUR helpers." [1] [1] https://wiki.archlinux.org/index.php/Makepkg#Usage

On Sat, 25 Apr 2015 17:51:10 +0200, Neven Sajko wrote:

nano

IMO nano should be part of base. Other editors might have advantages over nano, but to set up config files, it's on of the most easiest to use editors. It's my default editor, because you don't get a tendonitis and you don't need to learn billions of shortcuts and a strange language to configure the editor, IOW it's not like Emacs and it's also not like the two modes Vi/m, "beep repeatedly" and "break everything". Sure, for coders those editors have their advantages, but to set up an install nano is a good choice, because it can be used by everybody. Perhaps by default an improved nanorc should be provided.

On 25 April 2015 at 19:59, Sam Stuewe wrote:

This may just be my personal opinion, but I have always thought that `base` was supposed to be the absolute bare minimum to have a bootable installation. From that view, it makes sense that a few very small editors made sense in `base` back when Arch wasn't net-install only.

​I would say an editor is part of the bare minimum for any system. You can't do much on a system without an editor (of course you can still edit files using some basic tools that don't qualify as editors, but that's besides the point).

Honestly, I think an idea world would put pacman, linux, systemd, bash, a few bootloaders, efi-related utilities and their dependencies in `base` and essentially nothing else.

​Multiple bootloaders don't really make sense​, and there are many bootloaders to choose from. Choosing one to install by default would probably be a very difficult discussion. It would also mean that users might not even be aware of what bootloader they're using and leave them unprepared when it breaks. Having said that, I think it makes perfect sense to have nano and

vim-minimal on the installation media, but I think of “what is on the installation media” and “what is in `base`” as being two separate things.

​ They are two separate​ things already. The installation media comes with wpa_supplicant for one. Kinds regards, Maarten

On 25 April 2015 at 20:18, Sam Stuewe wrote:

On Sat, Apr 25, 2015 at 08:10:57PM +0200, Maarten de Vries wrote:

...

I would say an editor is part of the bare minimum for any system. You can't do much on a system without an editor (of course you can still edit files using some basic tools that don't qualify as editors, but that's besides the point). I don't actually agree. Editing configs post install is not required for a bootable install (as made obvious by the fact that you can boot to it). Besides, once a user has booted, they can just install whatever editor they so choose anyway.

​Fair enough, if you define minimal as "it can boot", then you don't need an editor. I would interpret the "system" part in "a minimal booting system" as a system that can perform some basic tasks like editing files though.

They are two separate things already. The installation media comes with

...

wpa_supplicant for one. Right. I'm not actually arguing for wpa_supplicant's inclusion in `base`, just pointing out that things like, `netctl` (and imho, the variety of text editors) might not make sense either if we assume `base` is exclusively for a bootable install.

​Right, I don't really see a point in having netctl in base either, personally. I don't really mind either though. I do see a point for an editor in there. Then again, it's all very subjective anyway.

...

Kinds regards, And the same to you.

​And you ;)​ Kind regards, Maarten​ ​

I second the motion for a network group. I've been bitten by a lack of wpa_supplicant on a laptop install more than once. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

On 04/27/2015 06:02 PM, LoneVVolf wrote:

Are 2 packages really worth it to create an additonal group or do you propose to remove dhcpcd & iproute2 from base to this new group ?

No two packages are not worth to create an additional group, but if the base group should be as minimal as possible to boot up and since there are no bootloaders in it, why not remove dhcpcd & iproute2 and put these things together in a new group called network. I know that sounds strange, but why should someone who have installed the base group be able to get connected to the world through the wired connection, but not through the wireless? I know that a wired connection is more common, but isn't it better to have a clear distinction between a functional booting system, a functional booting system including network stuff and such things. Don't get me wrong, but it is annoying to configure the whole wirless stuff and netctl just said, STOP! There is ONE missing dependency: wpa_supplicant. ONLY ONE PACKAGE I MISSED TO REACH THE WORLD :-( :-) cheers h8h

On Tue, Apr 28, 2015, at 07:13, Rashif Ray Rahman wrote:

On 28 April 2015 at 05:21, H8H wrote:

...

Don't get me wrong, but it is annoying to configure the whole wirless stuff and netctl just said, STOP! There is ONE missing dependency: wpa_supplicant. ONLY ONE PACKAGE I MISSED TO REACH THE WORLD :-(

You are given the freedom to choose what to install when you pacstrap your system. You assumed the pacstrap would mirror the live environment, and never bothered to check what "base" actually includes, or whether your system has been configured as intended.

-- GPG/PGP ID: C0711BF1

I'll reserve my opinions on including wpa_supplicant in base, but I feel that it at least deserves a mention in the Arch Installation Guide. It's strange to me that the installer has better networking support than the base system. I've installed Arch on 5 different laptops, and I've forgotten about wpa_supplicant on every one of them. Maybe something like "Other packages or groups can be installed by appending their names to the above command (space seperated), possibly including the boot loader or wireless networking packages" under "Install the base packages". Thoughts?

On , LoneVVolf wrote:

Given that dhcpcd & iproute2 are already in the base group, wired networking is already supported by installing base.

Technical note: It's not enough on all wired networks, X802.1x needs wpa_supplicant. I forget it almost always I reinstall one of my machines.. P. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

thanks :) It's only ONE damn tool to make all users happy. And some of them bad, because wpa_supplicant has some vulnerabilities. But its only one tool, everything you forgot to install on the live medium can installed afterwards, but not wpa_supplicant or other missing network tools. cheers On 04/28/2015 08:10 PM, Feirlane wrote:

And wpa_supplicant is an opt-depend of netctl, but maybe it should indicate it's needed for X802.1x as it currently only says it's for wireless networking.

-- GPG Key: 8387FCC3

On Tue, Apr 28, 2015 at 8:00 PM, Paladin wrote:

...

On , LoneVVolf wrote:

...

Given that dhcpcd & iproute2 are already in the base group, wired networking is already supported by installing base.

Technical note: It's not enough on all wired networks, X802.1x needs wpa_supplicant. I forget it almost always I reinstall one of my machines..

P. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

On Mon, Apr 27, 2015, at 02:46 PM, Eli Schwartz wrote:

On Mon, Apr 27, 2015 at 1:32 AM, William Hatch wrote: Why automatically assume everyone needs RAID, or encrypted filesystems? I am fine with keeping in tools for not-so-common filesystem types, though I will still remove them myself.

All these are things that it can be reasonably expected many many people won't ever use. base should be restricted to things that everyone agrees should be part of an Arch system.

I agree that the base group should be as minimal as is realistic, but I think cryptsetup belongs in base. FDE should be standard install procedure since most modern x86_64 processors have hardware accelerated AES (minimal overhead). -- vixsomnis

On Sat, 25 Apr 2015 12:59:30 -0500, Sam Stuewe wrote:

Honestly, I think an idea world would put pacman, linux, systemd, bash, a few bootloaders, efi-related utilities and their dependencies in `base` and essentially nothing else.

I guess _core_ should be similar to FreeBSD's world, including "the kernel, core system binaries, libraries, programming files, and built-in compiler". Basic software that gets more attention not to break by updates and more attention regarding security. Arch might not need a compiler for _base_, because building from ABS isn't needed, since we can install binaries using pacman. As somebody already pointed out, there are base and base-devel and even dash is exclude from both, so those groups already are very small. IMO base could include everything from core.

People forget vi(1) is part of POSIX so required on "systems that both support the User Portability Utilities option and define the POSIX2_CHAR_TERM symbol." [http://pubs.opengroup.org/onlinepubs/9699919799/ ]

The former is probably a good idea, seeing as the User Portability Utilities option in POSIX is written to be: "a requirement for a user portability interactive system. It is required frequently except for those systems, such as embedded realtime or dedicated application systems, that support little or no interactive time-sharing work by users or operators"

The latter is defined to mean that at least one terminal type has all user control options.

Unless Arch Linux wants to be deliberately non-POSIX compatible, vi should be in base.

The Linux kernel, glibc and various GNU utilities already deliberately deviate from POSIX compatibility in many ways. I don't think it's a very important consideration, just trivia. It's great to have vim-minimal on the install media (which is now the case), but that doesn't mean it needs to be in base.

Op 28 apr. 2015 21:04 schreef "Bardur Arantsson" :

On 28-04-2015 20:39, Daniel Micay wrote:

...

...

People forget vi(1) is part of POSIX so required on "systems that both support the User Portability Utilities option and define the POSIX2_CHAR_TERM symbol." [

http://pubs.opengroup.org/onlinepubs/9699919799/

...

...

] [...] It's great to have vim-minimal on the install media (which is now the case), but that doesn't mean it needs to be in base.

Indeed, AFAICT the only important thing to consider here is whether the booted system is "fixable" from within itself if you forgot to install something during the boot from install media. (E.g. by forgetting to install *some* editor or other. Everybody likes different editors, but "nano" will do until you can install something better.)

A very nice thing about having vi installed by default, is that you don't have to think about which editors are available. It's a unix(y) system, so vi just works. No need to remember if it's nano/pico/whatever on this specific distro. It's easy enough to add one's favorite editor when installing. On Windows, for example, i assume notepad is available, Word etc are optional (though I usually keep (g)vim on systems I use often). Mvg, Guus

On 25 April 2015 at 19:36, Ralf Mardorf wrote:

On Sat, 25 Apr 2015 17:51:10 +0200, Neven Sajko wrote:

...

nano

IMO nano should be part of base. Other editors might have advantages over nano, but to set up config files, it's on of the most easiest to use editors. It's my default editor, because you don't get a tendonitis and you don't need to learn billions of shortcuts and a strange language to configure the editor, IOW it's not like Emacs and it's also not like the two modes Vi/m, "beep repeatedly" and "break everything". Sure, for coders those editors have their advantages, but to set up an install nano is a good choice, because it can be used by everybody. Perhaps by default an improved nanorc should be provided.

I didn't use nano much but I'm pretty sure you could edit text faster in MS Word, so I cannot imagine any scenario in which it should be used. If you don't know how to use anything better you should probably learn ASAP.

On 26 April 2015 at 00:24, Ralf Mardorf wrote:

On Sat, 25 Apr 2015 23:55:32 +0200, Neven Sajko wrote:

...

On 25 April 2015 at 19:36, Ralf Mardorf wrote:

...

On Sat, 25 Apr 2015 17:51:10 +0200, Neven Sajko wrote:

...

nano

IMO nano should be part of base. Other editors might have advantages over nano, but to set up config files, it's on of the most easiest to use editors. It's my default editor, because you don't get a tendonitis and you don't need to learn billions of shortcuts and a strange language to configure the editor, IOW it's not like Emacs and it's also not like the two modes Vi/m, "beep repeatedly" and "break everything". Sure, for coders those editors have their advantages, but to set up an install nano is a good choice, because it can be used by everybody. Perhaps by default an improved nanorc should be provided.

I didn't use nano much but I'm pretty sure you could edit text faster in MS Word, so I cannot imagine any scenario in which it should be used. If you don't know how to use anything better you should probably learn ASAP.

Mentioning a Windows office suite is polemic. Even a lot of us *nix users nowadays are using GUI editors, Sublime text, Pluma, Atom editor, Gvim etc. for tasks an editor usually is used for, unlikely for editing office work. For some tasks a GUI isn't an option, usually for editing simple config files something as Nano can be used by nearly everybody. Most of us for sure are aware how to use Vi too. I prefer to get Nano when e.g. running visudo, but sure, I'm able to use Vi/m too.

I'm not an editor war guy. There's nothing wrong with Emacs and Vi/m, but there's also nothing wrong with easy to use, self explaining editors such as Nano, mcedit etc., even while Vi is a standard.

Why not providing an easy to use self explaining editor such as Nano? You don't benefit from a "better" editor for this task. Why should people learn how to use oldish editors, they never need for simple tasks, when we nowadays have much easier, self-explaining editors, such as nano?

Do you seriously consider $ pacman -Qi nano | grep Size Installed Size : 2.05 MiB in base as an issue? 2.05 MiB that make live for many users much easier.

Regards, Ralf

Having nano installed wouldn't bother me much, but I think that if it prevents people from using faster editors it is probably not beneficial.