Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
The `base` group has been replaced by a metapackage of the same name, we advise users to install this package (`pacman -Syu base`), as it is effectively mandatory from now on.
Please, was this discussed somewhere? I want to know the details, and gather what is needed to update the 'Installation guide' article in the wiki. In particular, I want to understand why essential packages for new installations, such as the kernel and a text editor, are not included (actually I see the kernel is an optional dependency). Thanks, Marc
Hi, Le 07/10/2019 à 06:02, Marc Ranolfi via arch-general a écrit :
The `base` group has been replaced by a metapackage of the same name, we advise users to install this package (`pacman -Syu base`), as it is effectively mandatory from now on.
Please, was this discussed somewhere?
Yes, please see https://lists.archlinux.org/pipermail/arch-dev-public/2019-January/029435.ht... and https://lists.archlinux.org/pipermail/arch-dev-public/2019-March/029491.html.
I want to know the details, and gather what is needed to update the 'Installation guide' article in the wiki.
Please join ongoing discussion here: https://wiki.archlinux.org/index.php/Talk:Installation_guide#Changes_for_the...
In particular, I want to understand why essential packages for new installations, such as the kernel and a text editor, are not included (actually I see the kernel is an optional dependency).
Because neither of those are needed in e.g. container environment. Actually we are discussing reducing base even further, just look at recent bugs in the bug tracker. A regular user likely will want some kernel (but the linux package is only one possible recommandation, we could also maybe turn this optdep into some virtual one like `kernel` that would then be provided by all our kernels), a text editor (but neither vi, nano nor anything else are mandatory either), etc. Regards, Bruno/Archange
Em outubro 7, 2019 1:02 Marc Ranolfi via arch-general escreveu:
The `base` group has been replaced by a metapackage of the same name, we advise users to install this package (`pacman -Syu base`), as it is effectively mandatory from now on.
Please, was this discussed somewhere? I want to know the details, and gather what is needed to update the 'Installation guide' article in the wiki. In particular, I want to understand why essential packages for new installations, such as the kernel and a text editor, are not included (actually I see the kernel is an optional dependency).
Yes, this was discussed over the years in several threads. The most recent being [0]. Lacking a kernel is mainly for container based environments. And some superfluous packages were also removed from the group, like an editor. The necessary changes to the installation guide were already made [1]. Regards, Giancarlo Razzolini https://lists.archlinux.org/pipermail/arch-dev-public/2019-January/029435.ht... https://wiki.archlinux.org/index.php/Installation_guide#Install_the_base_pac...
Right. Thanks guys. Marc On Mon, Oct 7, 2019 at 1:22 AM Giancarlo Razzolini via arch-general < arch-general@archlinux.org> wrote:
Em outubro 7, 2019 1:02 Marc Ranolfi via arch-general escreveu:
The `base` group has been replaced by a metapackage of the same name, we advise users to install this package (`pacman -Syu base`), as it is effectively mandatory from now on.
Please, was this discussed somewhere? I want to know the details, and gather what is needed to update the 'Installation guide' article in the wiki. In particular, I want to understand why essential packages for new installations, such as the kernel and a text editor, are not included (actually I see the kernel is an optional dependency).
Yes, this was discussed over the years in several threads. The most recent being [0].
Lacking a kernel is mainly for container based environments. And some superfluous packages were also removed from the group, like an editor.
The necessary changes to the installation guide were already made [1].
Regards, Giancarlo Razzolini
https://lists.archlinux.org/pipermail/arch-dev-public/2019-January/029435.ht...
https://wiki.archlinux.org/index.php/Installation_guide#Install_the_base_pac...
On 10/06/2019 11:22 PM, Giancarlo Razzolini via arch-general wrote:
Yes, this was discussed over the years in several threads. The most recent being [0].
Lacking a kernel is mainly for container based environments. And some superfluous packages were also removed from the group, like an editor.
The necessary changes to the installation guide were already made [1].
All of this seems like a lot of unnecessary shuffling to what has been a reliable base install for the past decade. Why on earth no simply create a 'base-container' group to provide the install for those desiring an install to support containers and leave the traditional base group alone. The lack cryptsetup, device-mapper, dhcpcd, mdadm, netctl, s-nail, vi and which in base seems to leave a 'base' install very unusable. -- David C. Rankin, J.D.,P.E.
On 10/8/19 2:20 PM, David C. Rankin wrote:
On 10/06/2019 11:22 PM, Giancarlo Razzolini via arch-general wrote:
Yes, this was discussed over the years in several threads. The most recent being [0].
Lacking a kernel is mainly for container based environments. And some superfluous packages were also removed from the group, like an editor.
The necessary changes to the installation guide were already made [1].
All of this seems like a lot of unnecessary shuffling to what has been a reliable base install for the past decade. Why on earth no simply create a 'base-container' group to provide the install for those desiring an install to support containers and leave the traditional base group alone. The lack cryptsetup, device-mapper, dhcpcd, mdadm, netctl, s-nail, vi and which in base seems to leave a 'base' install very unusable.
Because this is not about containers. There are tons of things in the old base group which I don't want installed on my heavyweight X11 desktop which is used for media consumption. I don't need netct (because networkmanager is love), s-nail (unuseful in practice) or vi (symlink to vim) as a baseline fact. I don't need cryptsetup or device-mapper if I'm not opting into an encrypted filesystem, but this does not matter as I cannot get rid of either one due to systemd performing shared library links to libcryptsetup.so and therefore also having a depends+=('cryptsetup') I do not need mdadm or lvm2, because I don't use RAID or lvm, so why do you think my system is unusable without it? Note: in practice, both are required by libblockdev, which means if you use udisks2 you have both installed anyway. -- Eli Schwartz Bug Wrangler and Trusted User
On 10/08/2019 01:33 PM, Eli Schwartz via arch-general wrote:
Because this is not about containers. There are tons of things in the old base group which I don't want installed on my heavyweight X11 desktop which is used for media consumption.
I don't need netct (because networkmanager is love), s-nail (unuseful in practice) or vi (symlink to vim) as a baseline fact.
I don't need cryptsetup or device-mapper if I'm not opting into an encrypted filesystem, but this does not matter as I cannot get rid of either one due to systemd performing shared library links to libcryptsetup.so and therefore also having a depends+=('cryptsetup')
I do not need mdadm or lvm2, because I don't use RAID or lvm, so why do you think my system is unusable without it? Note: in practice, both are required by libblockdev, which means if you use udisks2 you have both installed anyway.
As long at it passes the Allan test, then so be it. I do use mdadm, netctl, s-nail (mailx) but agree with vim as baseline. The point being no kernel? So now a 'base' install does not result in a running system? It seems like forcing the install of `base` + (a list of other packages) just to result in a bootable system will create more problems then it solves. At least a meta of 'base-legacy' would provide the same install capability. As for the argument advances that this was due to those looking for a container install, why not create a 'base-container' or 'base-minimal' and leave the traditional 'base' alone? -- David C. Rankin, J.D.,P.E.
On 10/8/19 1:45 PM, David C. Rankin wrote:
On 10/08/2019 01:33 PM, Eli Schwartz via arch-general wrote:
Because this is not about containers. There are tons of things in the old base group which I don't want installed on my heavyweight X11 desktop which is used for media consumption.
I don't need netct (because networkmanager is love), s-nail (unuseful in practice) or vi (symlink to vim) as a baseline fact.
I don't need cryptsetup or device-mapper if I'm not opting into an encrypted filesystem, but this does not matter as I cannot get rid of either one due to systemd performing shared library links to libcryptsetup.so and therefore also having a depends+=('cryptsetup')
I do not need mdadm or lvm2, because I don't use RAID or lvm, so why do you think my system is unusable without it? Note: in practice, both are required by libblockdev, which means if you use udisks2 you have both installed anyway. As long at it passes the Allan test, then so be it. I do use mdadm, netctl, s-nail (mailx) but agree with vim as baseline. The point being no kernel? So now a 'base' install does not result in a running system? It seems like forcing the install of `base` + (a list of other packages) just to result in a bootable system will create more problems then it solves. At least a meta of 'base-legacy' would provide the same install capability. As for the argument advances that this was due to those looking for a container install, why not create a 'base-container' or 'base-minimal' and leave the traditional 'base' alone?
There are multiple kernels officially supported. Vanilla, lts, zen, hardened, etc. So it probably was left out of base because they didn't want to force people to take the extra step of changing kernels. Yaro
May I offer a suggestion and you may already be doing thi; its what I do to create Arch installs customized to my own needs. Either: a) Create a simple script with installs a list of packages you want. Can be as simple as a shell script with a list of commands like: pacman -S --needed linux linux-custom mdadm lvm2 pacman -S --needed networkmanager pacman -S --needed vi etc Adjust pacman options to taste or if you're a little more energetic and looking for a bit more fun: (b) create one or more personal meta packages which you can then simply pacman -U. Every install you do, just copy the script or package file(s) to new install and you get standard install just the way you want it. I suspect many arch users do something like this anyway. gene
You can take this one step further and create your own repo to host said packages. That way you can build aur stuff in one place and deploy it out to a few machines at once. We have about 4+ arch machines in the house and this is where we are headed. On Tue, Oct 8, 2019 at 3:54 PM Genes Lists via arch-general < arch-general@archlinux.org> wrote:
May I offer a suggestion and you may already be doing thi; its what I do to create Arch installs customized to my own needs.
Either:
a) Create a simple script with installs a list of packages you want. Can be as simple as a shell script with a list of commands like: pacman -S --needed linux linux-custom mdadm lvm2 pacman -S --needed networkmanager pacman -S --needed vi etc
Adjust pacman options to taste
or if you're a little more energetic and looking for a bit more fun:
(b) create one or more personal meta packages which you can then simply pacman -U.
Every install you do, just copy the script or package file(s) to new install and you get standard install just the way you want it.
I suspect many arch users do something like this anyway.
gene
On 10/7/19 12:02 AM, Marc Ranolfi via arch-general wrote:
The `base` group has been replaced by a metapackage of the same name, we advise users to install this package (`pacman -Syu base`), as it is effectively mandatory from now on.
Please, was this discussed somewhere? I want to know the details, and gather what is needed to update the 'Installation guide' article in the wiki. In particular, I want to understand why essential packages for new installations, such as the kernel and a text editor, are not included (actually I see the kernel is an optional dependency).
Really, I wish we would do as I'd wanted and transfer the "essential packages" which aren't actually essential and were thus not included in base.. to a new *group* called "base-extras", which would reflect its status as being mere recommendations, while providing a convenient way to choose to interactively install them, and allowing the Installation Guide to transition from: pacstrap /mnt base to pacstrap /mnt base base-extras instead of becoming "and also decide whether you want the kernel, and also probably linux-firmware (but check whether your hardware needs firmware first), and oh, if you want a text editor, go install one of those too I guess, and in case you feel super surprised later when info and man don't work, you might want to install texinfo and man-db (and man-pages if you also want manpages) and a dozen other things that most people want even if they don't realize it". And now we need to cherry-pick tons of packages for the archiso, and we need to cherry-pick tons of packages into the installation guide, and there is nothing straightforward to tell anyone what to do today. So we've taken a step forward and a step back, and mostly weren't ready for it either way. -- Eli Schwartz Bug Wrangler and Trusted User
The base-extras group really sounds like a great solution. Please consider this approach! Obviously, you don't need to re-install Arch too often, but I like to experiment with various configurations on various machines and I have gotten used to what is in that base group. Thanks! Paul Stoetzer On Tue, Oct 8, 2019 at 4:34 PM Eli Schwartz via arch-general <arch-general@archlinux.org> wrote:
On 10/7/19 12:02 AM, Marc Ranolfi via arch-general wrote:
The `base` group has been replaced by a metapackage of the same name, we advise users to install this package (`pacman -Syu base`), as it is effectively mandatory from now on.
Please, was this discussed somewhere? I want to know the details, and gather what is needed to update the 'Installation guide' article in the wiki. In particular, I want to understand why essential packages for new installations, such as the kernel and a text editor, are not included (actually I see the kernel is an optional dependency).
Really, I wish we would do as I'd wanted and transfer the "essential packages" which aren't actually essential and were thus not included in base.. to a new *group* called "base-extras", which would reflect its status as being mere recommendations, while providing a convenient way to choose to interactively install them, and allowing the Installation Guide to transition from:
pacstrap /mnt base
to
pacstrap /mnt base base-extras
instead of becoming "and also decide whether you want the kernel, and also probably linux-firmware (but check whether your hardware needs firmware first), and oh, if you want a text editor, go install one of those too I guess, and in case you feel super surprised later when info and man don't work, you might want to install texinfo and man-db (and man-pages if you also want manpages) and a dozen other things that most people want even if they don't realize it".
And now we need to cherry-pick tons of packages for the archiso, and we need to cherry-pick tons of packages into the installation guide, and there is nothing straightforward to tell anyone what to do today. So we've taken a step forward and a step back, and mostly weren't ready for it either way.
-- Eli Schwartz Bug Wrangler and Trusted User
On 10/8/19 4:34 PM, Eli Schwartz via arch-general wrote:
Really, I wish we would do as I'd wanted and transfer the "essential packages" which aren't actually essential and were thus not included in base.. to a new *group* called "base-extras", which would reflect its status as being mere recommendations, while providing a convenient way to choose to interactively install them, and allowing the Installation Guide to transition from:
Sounds good to me - do you have a suggested list of packages for base-extras or at least the list of what was pulled from the old base. Might be good for folks to add those to private install script / meta package until such time as base-extras may be available. Thanks for mentioning linux-firmware - I just added kernels and a few other items to my own, but I missed that one
On Tue, Oct 8, 2019 at 9:49 PM Genes Lists via arch-general < arch-general@archlinux.org> wrote:
On 10/8/19 4:34 PM, Eli Schwartz via arch-general wrote:
Really, I wish we would do as I'd wanted and transfer the "essential packages" which aren't actually essential and were thus not included in base.. to a new *group* called "base-extras", which would reflect its status as being mere recommendations, while providing a convenient way to choose to interactively install them, and allowing the Installation Guide to transition from:
Sounds good to me - do you have a suggested list of packages for base-extras or at least the list of what was pulled from the old base.
Might be good for folks to add those to private install script / meta package until such time as base-extras may be available.
Thanks for mentioning linux-firmware - I just added kernels and a few other items to my own, but I missed that one
Possibly intel-ucode would be very useful for many installs as well? -- mike c
On Wednesday, October 9, 2019 12:03 PM, Mike Cloaked via arch-general <arch-general@archlinux.org> wrote:
Possibly intel-ucode would be very useful for many installs as well?
Except for people who need amd-ucode... For a long time I was under the impression we relied on derivative distros to dumb down things like system maintenance and installation for "regular" users. The proposed "base-extra" group might be a marginally useful idea, but the effort seems like a shot in the dark. What problem are we solving, really? cheers! mar77i Sent with ProtonMail Secure Email.
The problem is that reducing the base group to the bare minimum made the installation of Arch much more complicated for the average or even moderately experienced user. I am not certain which packages I would even need to replicate the experience I am used to. A base-extra group would allow less experienced users to get a working installation done in a similar way as it has for the last ten years with the addition of one extra entry on the pacstrap command instead of having to sort through and determine which packages are needed after this change. I understand that Arch is developed to be simple for the developers and not the users, all I think many of us are asking for is a way to replicate the previous install mechanism with one small addition (a base-extra group that includes all the packages removed from base by this change). Thanks, Paul Stoetzer On Wed, Oct 9, 2019 at 06:15 mar77i via arch-general < arch-general@archlinux.org> wrote:
On Wednesday, October 9, 2019 12:03 PM, Mike Cloaked via arch-general < arch-general@archlinux.org> wrote:
Possibly intel-ucode would be very useful for many installs as well?
Except for people who need amd-ucode...
For a long time I was under the impression we relied on derivative distros to dumb down things like system maintenance and installation for "regular" users. The proposed "base-extra" group might be a marginally useful idea, but the effort seems like a shot in the dark. What problem are we solving, really?
cheers! mar77i
Sent with ProtonMail Secure Email.
Hi, i am not clear why the base group is being replaced.. i searched in wiki and couldnt get a clear idea why. Could anyone plz explain?
Hi, there I like to say that the idea of having a base and base-extra meta package instead of previously base group is a great idea. For me Arch greatest strength is giving the user control and choice over their system and which software they need to install. Having a meta package for really essential packages which every Arch installation needs instead of previously general base group and having to choose which other package to install which some of them have alternatives like linux and linux-lts and so on, is exactly what that means to have choice and control over our system. I think many of complaints that arises with respect to this change is simply about not having enough information about these new changes and how from now on we must install a new Arch. That's where Arch other greatest strength come to play, our beloved wiki. A good explanation in installation page could solve that.
El jue., 10 oct. 2019 a las 4:27, Ram Kumar via arch-general (<arch-general@archlinux.org>) escribió:
Hi, i am not clear why the base group is being replaced.. i searched in wiki and couldnt get a clear idea why. Could anyone plz explain?
Yes. There is a plan to replace all package groups with metapackages? -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
Maybe I'm just old but not having a text editor by default in the rootfs seems wrong. I had a professor once say everyone should learn at least a few vi commands because "no matter what distro/ flavor of Unix you have to deal with vi will always be there". I admit one hundred percent that it doesn't need to be in base, and a simple pacstrap base vi solves the problem, but I still makes me uncomfortable knowing it isn't installed by default. I think thinning out base is a good idea however and vi is not necessary to boot a system. All that said I would be interested in a bit of the original design choices around the base package. Is there any historical information on why it was setup the way it was? Will the removal of the kernel by default from the package be replaced by a new depends/provided relationship where base depends on "kernel" and any of the kernel packages provide "kernel"? On Thu, Oct 10, 2019, 2:52 AM Óscar García Amor via arch-general < arch-general@archlinux.org> wrote:
El jue., 10 oct. 2019 a las 4:27, Ram Kumar via arch-general (<arch-general@archlinux.org>) escribió:
Hi, i am not clear why the base group is being replaced.. i searched in wiki and couldnt get a clear idea why. Could anyone plz explain?
Yes. There is a plan to replace all package groups with metapackages?
-- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
Hi Greg,
Maybe I'm just old ... everyone should learn at least a few vi commands ... I still makes me uncomfortable knowing it isn't installed by default.
Not old enough! Everyone should just learn ed(1). :-) -- Cheers, Ralph.
On Thu, 10 Oct 2019 at 10:41, Ralph Corderoy <ralph@inputplus.co.uk> wrote:
Hi Greg,
Maybe I'm just old ... everyone should learn at least a few vi commands ... I still makes me uncomfortable knowing it isn't installed by default.
Not old enough! Everyone should just learn ed(1). :-)
ed? They should learn how to edit a text file using assembly
On Thu, 10 Oct 2019 10:44:08 +0100 Andy Pieters <arch-general@andypieters.me.uk> wrote:
On Thu, 10 Oct 2019 at 10:41, Ralph Corderoy <ralph@inputplus.co.uk> wrote:
Hi Greg,
Maybe I'm just old ... everyone should learn at least a few vi commands ... I still makes me uncomfortable knowing it isn't installed by default.
Not old enough! Everyone should just learn ed(1). :-)
ed? They should learn how to edit a text file using assembly
Never mind Ed Vi Assemblers yes all very fancyfull hows about you just include joe far easier wordstar commands no mess just works the very first thing i ever do install joe best editor of the lot . Pete .
I think we should have created a "minimal" group rather than repurposing the base one. Then as a separate issue to tackle, add "kernel" and "editor" etc to the base group which would prompt the user to choose, or if non-interactive install the first listed. -- Jonathan Steel Trusted User
On Thu, Oct 10, 2019 at 8:14 AM Jonathan Steel via arch-general <arch-general@archlinux.org> wrote:
I think we should have created a "minimal" group rather than repurposing the base one. Then as a separate issue to tackle, add "kernel" and "editor" etc to the base group which would prompt the user to choose, or if non-interactive install the first listed.
Yes indeed. I too think this would be so much less of a breaking change. I think this is more sane than changing 'base' as it is already done and then providing a 'base-extras'. But, it is already done, so I don't know.
I am sorry if this is a repeated/dumb question. What exactly does the base package have? I.e. if i install only base "pacstrap /mnt base", then what stuff will i get in it? Knowing this i can decide what stuff i have to install in addition.
On 10/10/19 7:14 AM, Jonathan Steel via arch-general wrote:
I think we should have created a "minimal" group rather than repurposing the base one. Then as a separate issue to tackle, add "kernel" and "editor" etc to the base group which would prompt the user to choose, or if non-interactive install the first listed.
Groups don't "depend" on things like virtual provides=(), you tag an actual .pkg.tar.xz with a group and then search for every pkgname that has that group. So I'm not sure what you are suggesting here. But regardless, we very explicitly wanted to *not* use the name "base" for recommendations, because it does not make clear that it is in fact recommendations. So the choices were either get rid of the base group and make a base package, or also get rid of the base group, but make a package named something entirely differently. There is no option on the table for there to continue to be a confusing group named "base". If you're really in love with groups and don't want to see a metapackage then once again we would still need to delete the base group in order to create a "minimal" group, and any group of recommendations would need to be named something like, oh, "base-extras". So, once again, you would not be able to `pacstrap /mnt base`. Some changes were always inevitable. -- Eli Schwartz Bug Wrangler and Trusted User
On Thu, Oct 10, 2019 at 9:36 PM Eli Schwartz via arch-general <arch-general@archlinux.org> wrote:
But regardless, we very explicitly wanted to *not* use the name "base" for recommendations, because it does not make clear that it is in fact recommendations.
So the choices were either get rid of the base group and make a base package, or also get rid of the base group, but make a package named something entirely differently. There is no option on the table for there to continue to be a confusing group named "base".
(...) Some changes were always inevitable.
Ok, I'm convinced. p.s.: nano is _fine_.
Hi Pete,
Everyone should just learn ed(1). :-)
ed? They should learn how to edit a text file using assembly
Never mind Ed Vi Assemblers yes all very fancyfull
My ed suggestion wasn't a joke. It's probably the smallest editor to install. It has a long pedigree, it's in POSIX, and many know parts of it simply through knowing sed or vi. I use it every day for quick small edits, especially when the context of what I want to do is on the screen and would be lost by starting a full-screen editor.
joe far easier wordstar commands
Few know the non-Unix Wordstar now. -- Cheers, Ralph.
On 10/10/19 10:14 AM, Ralph Corderoy wrote:
Everyone should just learn ed(1). :-)
ed? They should learn how to edit a text file using assembly
Don't take this the wrong way, but if I have to write my own text editor in assembly (not to mention an assembler and possibly a linker) just to install Arch, then I'm switching distros. Besides, C-x M-c M-butterfly is so much better.
Never mind Ed Vi Assemblers yes all very fancyfull
My ed suggestion wasn't a joke. It's probably the smallest editor to install. It has a long pedigree, it's in POSIX, and many know parts of it simply through knowing sed or vi. I use it every day for quick small edits, especially when the context of what I want to do is on the screen and would be lost by starting a full-screen editor.
joe far easier wordstar commands
Few know the non-Unix Wordstar now.
I know Wordstar, and I agree with Ralph: ed(1) is in POSIX, it's tiny, and it's not as unfamiliar as people think. It also works with a plain dumb tty (misconfigured remote shell, anyone?), as opposed to requiring a cursor addressable or more capable terminal.
On 10/10/19 7:01 AM, pete via arch-general wrote:
Never mind Ed Vi Assemblers yes all very fancyfull hows about you just include joe far easier wordstar commands no mess just works the very first thing i ever do install joe best editor of the lot .
I have never heard of "joe". I have heard of many other text editors though. Off the top of my head: vi vim neovim vis ed emacs acme gedit pluma xed geany leafpad kate nano (gross) vscode atom sublime text notepad++ Windows Notepad Maybe if I even know Windows and macOS and *plan9* text editors before I know of this "joe", it needs to do better advertising. What are its features? Why would I want to use it? What merit does it have that we should recommend people use it? I have run pacman -Si joe, and it seems to be an editor. It's self-described as "Joe's own editor". So let me revise my question: who is joe, why do I care who he is, and what does his personal editor do for me? For that matter, if it carefully described as his own editor, am I allowed to use it? Alternatively, is it designed to be used by other people than its original intendee? -- Eli Schwartz Bug Wrangler and Trusted User
I've been following this discussion and can't see what the actual problem is. I've installed a new system since the change and the installation doc's have been updated appropriately. It still works. If you want extra packages then add them, this, in my opinion, is what Arch is designed to do. I'm not seeing why extra packages need to be installed based upon personal preference. On Thu, Oct 10, 2019, 6:48 PM Eli Schwartz via arch-general < arch-general@archlinux.org> wrote:
On 10/10/19 7:01 AM, pete via arch-general wrote:
Never mind Ed Vi Assemblers yes all very fancyfull hows about you just include joe far easier wordstar commands no mess just works the very first thing i ever do install joe best editor of the lot .
I have never heard of "joe". I have heard of many other text editors though. Off the top of my head:
vi vim neovim vis ed emacs acme gedit pluma xed geany leafpad kate nano (gross) vscode atom sublime text notepad++ Windows Notepad
Maybe if I even know Windows and macOS and *plan9* text editors before I know of this "joe", it needs to do better advertising. What are its features? Why would I want to use it? What merit does it have that we should recommend people use it?
I have run pacman -Si joe, and it seems to be an editor. It's self-described as "Joe's own editor". So let me revise my question: who is joe, why do I care who he is, and what does his personal editor do for me? For that matter, if it carefully described as his own editor, am I allowed to use it? Alternatively, is it designed to be used by other people than its original intendee?
-- Eli Schwartz Bug Wrangler and Trusted User
On 10/10/19 9:00 PM, Nero Claudius Drusus via arch-general wrote:
I've been following this discussion and can't see what the actual problem is. I've installed a new system since the change and the installation doc's have been updated appropriately. It still works. If you want extra packages then add them, this, in my opinion, is what Arch is designed to do. I'm not seeing why extra packages need to be installed based upon personal preference. There's a community interest in something that helps you install high-profile packages such as:
man-db man-pages less diffutils texinfo vi (required by the POSIX User Portability option, commonly assumed to be "the text editor you have even when you don't have anything else") It is also easy, once you have something for that, to also have it prompt you to install: linux (most people's default kernel) linux-firmware These are some pretty reasonable basic assumptions to make, so it's not crazy to think maybe users should be able to have some group of these packages to make sure they don't forget anything. It's especially not obvious that suddenly you need to install the `man` program as well as the core set of linux manpages (containing the 1p section and most of the good stuff in sections 2 & 3). But also texinfo, if you want to be able to read most documentation from GNU projects which don't ship proper manpages. At what point does updated wiki documentation become a giant list of "here's the things 99.9999% of people need but you'll have to install separately after reading some caveat and if you don't, then you will not even be able to type in 'man' to figure out your mistakes while offline"? -- Eli Schwartz Bug Wrangler and Trusted User
Let's face the facts. Man is superfluous for most people learning how to install Arch, especially since it forces you to have an internet connection in order to install. The wiki installation page so far hasn't included any extras other than the kernel (at least that I've noticed thus far, please correct me if I'm wrong). If it creates a broken system then that's a legitimate point of contention, otherwise it's just adding a couple more packages to your install script which falls exactly inline with Arch's minimal philosophy. On Thu, Oct 10, 2019, 7:26 PM Eli Schwartz via arch-general < arch-general@archlinux.org> wrote:
I've been following this discussion and can't see what the actual problem is. I've installed a new system since the change and the installation doc's have been updated appropriately. It still works. If you want extra
On 10/10/19 9:00 PM, Nero Claudius Drusus via arch-general wrote: packages
then add them, this, in my opinion, is what Arch is designed to do. I'm not seeing why extra packages need to be installed based upon personal preference. There's a community interest in something that helps you install high-profile packages such as:
man-db man-pages less diffutils texinfo vi (required by the POSIX User Portability option, commonly assumed to be "the text editor you have even when you don't have anything else")
It is also easy, once you have something for that, to also have it prompt you to install:
linux (most people's default kernel) linux-firmware
These are some pretty reasonable basic assumptions to make, so it's not crazy to think maybe users should be able to have some group of these packages to make sure they don't forget anything. It's especially not obvious that suddenly you need to install the `man` program as well as the core set of linux manpages (containing the 1p section and most of the good stuff in sections 2 & 3). But also texinfo, if you want to be able to read most documentation from GNU projects which don't ship proper manpages.
At what point does updated wiki documentation become a giant list of "here's the things 99.9999% of people need but you'll have to install separately after reading some caveat and if you don't, then you will not even be able to type in 'man' to figure out your mistakes while offline"?
-- Eli Schwartz Bug Wrangler and Trusted User
I want to clarify that I didn't mean "man" requires an internet connection. Arch does and uses the wiki. On Thu, Oct 10, 2019, 7:49 PM Nero Claudius Drusus <germanicus1982@gmail.com> wrote:
Let's face the facts. Man is superfluous for most people learning how to install Arch, especially since it forces you to have an internet connection in order to install.
The wiki installation page so far hasn't included any extras other than the kernel (at least that I've noticed thus far, please correct me if I'm wrong). If it creates a broken system then that's a legitimate point of contention, otherwise it's just adding a couple more packages to your install script which falls exactly inline with Arch's minimal philosophy.
On Thu, Oct 10, 2019, 7:26 PM Eli Schwartz via arch-general < arch-general@archlinux.org> wrote:
I've been following this discussion and can't see what the actual
is. I've installed a new system since the change and the installation doc's have been updated appropriately. It still works. If you want extra
On 10/10/19 9:00 PM, Nero Claudius Drusus via arch-general wrote: problem packages
then add them, this, in my opinion, is what Arch is designed to do. I'm not seeing why extra packages need to be installed based upon personal preference. There's a community interest in something that helps you install high-profile packages such as:
man-db man-pages less diffutils texinfo vi (required by the POSIX User Portability option, commonly assumed to be "the text editor you have even when you don't have anything else")
It is also easy, once you have something for that, to also have it prompt you to install:
linux (most people's default kernel) linux-firmware
These are some pretty reasonable basic assumptions to make, so it's not crazy to think maybe users should be able to have some group of these packages to make sure they don't forget anything. It's especially not obvious that suddenly you need to install the `man` program as well as the core set of linux manpages (containing the 1p section and most of the good stuff in sections 2 & 3). But also texinfo, if you want to be able to read most documentation from GNU projects which don't ship proper manpages.
At what point does updated wiki documentation become a giant list of "here's the things 99.9999% of people need but you'll have to install separately after reading some caveat and if you don't, then you will not even be able to type in 'man' to figure out your mistakes while offline"?
-- Eli Schwartz Bug Wrangler and Trusted User
On Thu, 2019-10-10 at 19:49 -0600, Nero Claudius Drusus via arch-general wrote:
Let's face the facts. Man is superfluous for most people learning how to install Arch, especially since it forces you to have an internet connection in order to install.
What do you mean? You have the installation guide in the bootable image. If you don't know/remember how to use a specific tool, eg. parted, you can just man it. You don't actually need the archwiki, and I would consider man superfluous. You might now even need an internet connection, I run a local mirror at home. I am not saying this is common, just that it is possible and maybe some people might want to do it.
Hi, IMO it's a good idea that the Arch developers want to rework "base", but IMO the result is a bit overdone. Don't get me wrong, I can live with the current base package, if the developers like it, it's ok for me. However, I do understand that users are surprised that even vi/m is excluded. My contribution to the bike shed: On Thu, 10 Oct 2019 21:26:26 -0400, Eli Schwartz via arch-general wrote:
vi (required by the POSIX User Portability option, commonly assumed to be "the text editor you have even when you don't have anything else")
It _is_ or at least vim is, without doubts the editor most users, including the emacs users, expect as _the_ basic default editor. There obviously is a reason that some commands were named non-neutral, such as "visudo". While I'm in favour of nano for _simple_ editing, I don't expect that nano is installed, but I expect that vi/m is installed on even a minimal BSD or Linux install and I expect manual pages. Nano and mcedit are probably the most wanted "user-friendly" editors for _simple_ editing needs, but almost all users are able to handle vi/m, too, it just beeps a little bit, when inexperienced with using vi/m. GUI editors are probably irrelevant for a base install. IMO excluding manual pages and vi/m from a base install is unwise. That "less" is excluded is bizarre. I do understand that something such as "reiserfsprogs" and even "linux" is excluded, but there seems to be no rational reason for excluding "less". Is really anybody annoyed, if installing "less" is enforced? Could installing "less" make an install unnecessary bloated? especially if an editor is missing, "less" probably is a much wanted feature ;). But again, I can live with the current base package, if the developers like it, it's ok for me. By one way or another I anyway need to install a lot of packages, that without doubts don't belong to "base", next time I just need to install a few additional packages. Regards, Ralf
Hi Eli,
Off the top of my head:
vi vim ...
I was curious. Others might be interested in the result. $ expac -S '%m %n' vi vim neovim vis ed emacs acme gedit pluma xed \ > geany leafpad kate nano vscode atom | > sort -n 106496 ed 300032 vi 317440 leafpad 1076224 vis 2584576 nano 3707904 vim 12306432 xed 13692928 geany 15044608 gedit 20497408 neovim 21733376 kate 31233024 pluma 133710848 emacs 238760960 atom $ -- Cheers, Ralph.
Vi no, please. Nano is fine Greetings
On Fri, 11 Oct 2019 10:26:19 +0100, Ralph Corderoy wrote:
Hi Eli,
Off the top of my head:
vi vim ...
I was curious. Others might be interested in the result.
$ expac -S '%m %n' vi vim neovim vis ed emacs acme gedit pluma xed \
geany leafpad kate nano vscode atom | sort -n 106496 ed 300032 vi 317440 leafpad 1076224 vis 2584576 nano 3707904 vim 12306432 xed 13692928 geany 15044608 gedit 20497408 neovim 21733376 kate 31233024 pluma 133710848 emacs 238760960 atom $
An editor is a fundamental tool, so the install size most of the times is more or less irrelevant. For an editor way more important are features and/or easiness of usage. However, the real install size for example a GUI editor, such as e.g. "leafpad", for sure is way larger than that of vim, let alone that it is rendered useless, if only command line is available. $ pacman -Si leafpad gtk2 vim | grep -eName -e Depends Name : leafpad Depends On : gtk2 Name : gtk2 Depends On : atk pango libxcursor libxinerama libxrandr libxi libxcomposite libxdamage shared-mime-info cairo libcups gtk-update-icon-cache librsvg desktop-file-utils Name : vim Depends On : vim-runtime=8.1.2102-1 gpm acl glibc libgcrypt pcre zlib libffi If the target should be a small sized install, then even the current base package might not be the best starting point ;) [1]. Regards, Ralf [1] $ pacman -Qi busybox | grep -eDepends -eSize Depends On : None Installed Size : 1440.00 KiB "BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides replacements for most of the utilities you usually find in GNU fileutils, shellutils, etc." - https://www.busybox.net/about.html
Hi Ralf,
An editor is a fundamental tool
Yes, but stepping back a bit... do you accept that neither a text editor, or less(1), are required on a minimal install that's just being used as a base for producing a specialised install for a particular task, as used in a container? I'm unclear if you're arguing what should be in an add-on-to-base package for typical interactive use, or that the concept of stripping back base is wrong and should be reverted. -- Cheers, Ralph.
On Fri, 11 Oct 2019 11:33:51 +0100, Ralph Corderoy wrote:
Hi Ralf,
An editor is a fundamental tool
Yes, but stepping back a bit... do you accept that neither a text editor, or less(1), are required on a minimal install that's just being used as a base for producing a specialised install for a particular task, as used in a container?
I'm unclear if you're arguing what should be in an add-on-to-base package for typical interactive use, or that the concept of stripping back base is wrong and should be reverted.
Hi Ralph, first of all, the package "base" as is, is ok for me. _If_ the developers _would_ ask the Arch users, what packages to include again, I would at least vote for "less", "vim" and manual pages. If I run a Linux in a container, this Linux does not need a kernel, but actually "less" and an editor are needed by me... [root@archlinux moonstudio]# systemd-nspawn -bq [root@moonstudio ~]# uname -r; lsb_release -d 5.3.5-arch1-1-ARCH Description: Ubuntu 16.04.6 LTS [root@moonstudio ~]# less /etc/apt/sources.list [snip] [root@moonstudio ~]# visudo [snip] ...excluding the kernel, let alone packages to support exotic file systems, IMO is useful. I want the mainline kernel, even while most of the times I'm running real-time patched kernels, but I agree that the kernel should be optional. Removing the man pages, IOW the documentation by default is a very bad idea, since this is one of the benefits of BSD and Linux over opaque operating systems. I guess for special minimized installs users want to install something like BusyBox and remove man pages, as well as header files and even something like "grep" and other that are replaced by BusyBox, but such special cases IMO should not be reflected by a base install. That's my opinion, IOW next time I will install the base package and at least add "less", "vim", "nano" [1] and the man page related packages. Regards, Ralf [1] $ grep EDIT .bashrc export EDITOR="nano" "vim" because it's the lowest common denominator and "nano" because it's easier to use for simple editing. For advanced editing I'm in favour of a GUI editor. A lot of other users are probably even in favour of an IDE.
Howdy, I wonder if there shouldn't be two base packages. maybe a base-minimal for containers, and a base like the original. I worry that the new method will be confusing for people coming to Arch for the first time, and it kind of makes things a bit more strenuous for the bare metal user. Of course, this could just be because I am used to the old way. Will be interesting to see what happens. Thanks, Storm On Fri, Oct 11, 2019 at 05:20:46PM +0200, Arch Linux General wrote:
On Fri, 11 Oct 2019 11:33:51 +0100, Ralph Corderoy wrote:
Hi Ralf,
An editor is a fundamental tool
Yes, but stepping back a bit... do you accept that neither a text editor, or less(1), are required on a minimal install that's just being used as a base for producing a specialised install for a particular task, as used in a container?
I'm unclear if you're arguing what should be in an add-on-to-base package for typical interactive use, or that the concept of stripping back base is wrong and should be reverted.
Hi Ralph,
first of all, the package "base" as is, is ok for me.
_If_ the developers _would_ ask the Arch users, what packages to include again, I would at least vote for "less", "vim" and manual pages.
If I run a Linux in a container, this Linux does not need a kernel, but actually "less" and an editor are needed by me...
[root@archlinux moonstudio]# systemd-nspawn -bq [root@moonstudio ~]# uname -r; lsb_release -d 5.3.5-arch1-1-ARCH Description: Ubuntu 16.04.6 LTS [root@moonstudio ~]# less /etc/apt/sources.list [snip] [root@moonstudio ~]# visudo [snip]
...excluding the kernel, let alone packages to support exotic file systems, IMO is useful. I want the mainline kernel, even while most of the times I'm running real-time patched kernels, but I agree that the kernel should be optional.
Removing the man pages, IOW the documentation by default is a very bad idea, since this is one of the benefits of BSD and Linux over opaque operating systems.
I guess for special minimized installs users want to install something like BusyBox and remove man pages, as well as header files and even something like "grep" and other that are replaced by BusyBox, but such special cases IMO should not be reflected by a base install.
That's my opinion, IOW next time I will install the base package and at least add "less", "vim", "nano" [1] and the man page related packages.
Regards, Ralf
[1] $ grep EDIT .bashrc export EDITOR="nano"
"vim" because it's the lowest common denominator and "nano" because it's easier to use for simple editing. For advanced editing I'm in favour of a GUI editor. A lot of other users are probably even in favour of an IDE.
-- ⛈🐲 Accessible low cost computers for everyone! Get your slice of the Pi: https://asliceofthepi.com My youtube channel: https://www.youtube.com/channel/UCdaTl5vl404OaRxAJPvb8Ew get my public PGP key: gpg --keyserver wwwkeys.pgp.net --recv-key 43DDC193 Follow me on GNU Social: https://social.stormdragon.tk/storm "Death or glory i will find, Rebellion on my mind." Grave Digger - Rebellion (The Clans Are Marching)
I agree with you, I think having two base packages works well as it will help people who want an small container install but also people who just want a normal install. On Fri, Oct 11, 2019, 10:31 AM Storm Dragon via arch-general < arch-general@archlinux.org> wrote:
Howdy,
I wonder if there shouldn't be two base packages. maybe a base-minimal for containers, and a base like the original. I worry that the new method will be confusing for people coming to Arch for the first time, and it kind of makes things a bit more strenuous for the bare metal user.
Of course, this could just be because I am used to the old way. Will be interesting to see what happens.
Thanks, Storm
On Fri, Oct 11, 2019 at 05:20:46PM +0200, Arch Linux General wrote:
On Fri, 11 Oct 2019 11:33:51 +0100, Ralph Corderoy wrote:
Hi Ralf,
An editor is a fundamental tool
Yes, but stepping back a bit... do you accept that neither a text editor, or less(1), are required on a minimal install that's just being used as a base for producing a specialised install for a particular task, as used in a container?
I'm unclear if you're arguing what should be in an add-on-to-base package for typical interactive use, or that the concept of stripping back base is wrong and should be reverted.
Hi Ralph,
first of all, the package "base" as is, is ok for me.
_If_ the developers _would_ ask the Arch users, what packages to include again, I would at least vote for "less", "vim" and manual pages.
If I run a Linux in a container, this Linux does not need a kernel, but actually "less" and an editor are needed by me...
[root@archlinux moonstudio]# systemd-nspawn -bq [root@moonstudio ~]# uname -r; lsb_release -d 5.3.5-arch1-1-ARCH Description: Ubuntu 16.04.6 LTS [root@moonstudio ~]# less /etc/apt/sources.list [snip] [root@moonstudio ~]# visudo [snip]
...excluding the kernel, let alone packages to support exotic file systems, IMO is useful. I want the mainline kernel, even while most of the times I'm running real-time patched kernels, but I agree that the kernel should be optional.
Removing the man pages, IOW the documentation by default is a very bad idea, since this is one of the benefits of BSD and Linux over opaque operating systems.
I guess for special minimized installs users want to install something like BusyBox and remove man pages, as well as header files and even something like "grep" and other that are replaced by BusyBox, but such special cases IMO should not be reflected by a base install.
That's my opinion, IOW next time I will install the base package and at least add "less", "vim", "nano" [1] and the man page related packages.
Regards, Ralf
[1] $ grep EDIT .bashrc export EDITOR="nano"
"vim" because it's the lowest common denominator and "nano" because it's easier to use for simple editing. For advanced editing I'm in favour of a GUI editor. A lot of other users are probably even in favour of an IDE.
-- ⛈🐲 Accessible low cost computers for everyone! Get your slice of the Pi: https://asliceofthepi.com My youtube channel: https://www.youtube.com/channel/UCdaTl5vl404OaRxAJPvb8Ew get my public PGP key: gpg --keyserver wwwkeys.pgp.net --recv-key 43DDC193 Follow me on GNU Social: https://social.stormdragon.tk/storm "Death or glory i will find, Rebellion on my mind." Grave Digger - Rebellion (The Clans Are Marching)
Op vr 11 okt. 2019 17:34 schreef William Bevans via arch-general < arch-general@archlinux.org>:
I agree with you, I think having two base packages works well as it will help people who want an small container install but also people who just want a normal install.
People using containers should be using a specific set of packages, probably without any "base" groups, preferably installed by $automation system. Or exactly the other way around with a (container)metapackage for $webserver/rdbms/whatever (where the metapackage contains all *required* packages and nothing else. Mvg, Guus
Op wo 9 okt. 2019 12:15 schreef mar77i via arch-general < arch-general@archlinux.org>:
On Wednesday, October 9, 2019 12:03 PM, Mike Cloaked via arch-general < arch-general@archlinux.org> wrote:
Possibly intel-ucode would be very useful for many installs as well?
Except for people who need amd-ucode...
For a long time I was under the impression we relied on derivative distros to dumb down things like system maintenance and installation for "regular" users. The proposed "base-extra" group might be a marginally useful idea, but the effort seems like a shot in the dark. What problem are we solving, really?
AFAIK, the ease of "install this group" will be replaced with "please copy/paste this $reallylongline to get a usable base system when you're not deploying an (fully automated) container system. Arch is probably heading in a similar direction as Debian; a (relatively) low installed Base, with derivative distros using the same packages. Just my € 0,02 Mvg, Guus Snijders
On 10/9/19 6:15 AM, mar77i via arch-general wrote:
...What problem are we solving, really?
Problem: - there was a change - but the "diff" is not (obviously) visible, though I may have not looked in all the right places. The 'base' package has no history [1] - it came into existence 3 days ago. My view - be helpful to have a list of packages no longer in base. A list of what changed is needed so users can add whatever they deem appropriate (presumably a kernel is one) to their own personal install package and ensure installations proceeed as usual. So, if somone can provide a complete list of no-longer included packages that would be super helpfui so we can all adjust as needed. thanks. [1] https://git.archlinux.org/svntogit/packages.git/log/trunk?h=packages/base
On Wed, Oct 09, 2019 at 09:45:35 -0400, Genes Lists via arch-general wrote:
My view - be helpful to have a list of packages no longer in base.
A list of what changed is needed so users can add whatever they deem appropriate (presumably a kernel is one) to their own personal install package and ensure installations proceeed as usual.
So, if somone can provide a complete list of no-longer included packages that would be super helpfui so we can all adjust as needed.
https://web.archive.org/web/20190722121302/https://www.archlinux.org/groups/...
On 10/9/19 10:11 AM, Tinu Weber wrote:
https://web.archive.org/web/20190722121302/https://www.archlinux.org/groups/...
Perfect - thank you!
So, essentially if you want the full previous base group, you'd use # pacstrap /mnt base cryptsetup device-mapper dhcpcd diffutils e2fsprogs inetutils jfsutils less linux linux-firmware logrotate lvm2 man-db man-pages mdadm nano netctl perl reiserfsprogs s-nail texinfo usbutils vi which xfsprogs On Wed, Oct 9, 2019 at 10:19 AM Genes Lists via arch-general <arch-general@archlinux.org> wrote:
On 10/9/19 10:11 AM, Tinu Weber wrote:
https://web.archive.org/web/20190722121302/https://www.archlinux.org/groups/...
Perfect - thank you!
On Wed, 9 Oct 2019 10:19:38 -0400, Genes Lists via arch-general wrote:
On 10/9/19 10:11 AM, Tinu Weber wrote:
https://web.archive.org/web/20190722121302/https://www.archlinux.org/groups/...
Perfect - thank you!
IMO 'reiserfsprogs' is a good pointer for what reason to change 'base' makes sense ;). It's a package good for backwards compatibility, but probably not useful for a base install ;). -- “Awards are merely the badges of mediocrity.” ― Charles Ives
On 10/9/19 9:39 AM, Ralf Mardorf via arch-general wrote:
On 10/9/19 10:11 AM, Tinu Weber wrote:
https://web.archive.org/web/20190722121302/https://www.archlinux.org/groups/... Perfect - thank you! IMO 'reiserfsprogs' is a good pointer for what reason to change 'base' makes sense ;). It's a package good for backwards compatibility, but
On Wed, 9 Oct 2019 10:19:38 -0400, Genes Lists via arch-general wrote: probably not useful for a base install ;).
Heck, jfsutils. Does anyone actually use JFS outside of backwards compatibility support for older IBM systems? It bewilders me that it was in the original base group, honestly. Yaro
This will need checking into by screen reader experts, this change for probably more than one unknown reason not only broke accessibility, it made a system that did the grub beep and then had grub go spastic and the system could do nothing else. I have most of a braille page of pacstrap commands I'll run and see if I have any better luck installing archlinux the next time and that will be after coffee tomorrow and no sooner since this will need my undivided attention for a while. --
I, for one, think this isn’t going far enough. All packages should have explicit dependencies. I want to be able to run pacstrap ./dir nginx and get all the dependencies I need to run nginx inside a structure in dir. This would make arch very useful for chroot, namespaces and cgroups workflows (colloquially named “containerisation”). The old approach is silly. The complaints about the complexity of arch installs seem unusual in light of the fact that it’s already “difficult” and doesn’t really appear to have gotten any less difficult than it already was. The old base hasn’t been enough for a base system for me (and I assume most people) for years now while missing packages I would consider important and containing a bunch of unnecessary packages which I would happily do without except due to a lack of explicit dependencies I am not sure if my machine will still boot. If you’re worried about this change then there’s nothing stopping anyone from maintaining the far from perfect list of base group packages to install explicitly. — Tomasz Kramkowski
On 9 Oct 2019, at 22:11, Tinu Weber <takeya@bluewin.ch> wrote:
On Wed, Oct 09, 2019 at 09:45:35 -0400, Genes Lists via arch-general wrote: My view - be helpful to have a list of packages no longer in base.
A list of what changed is needed so users can add whatever they deem appropriate (presumably a kernel is one) to their own personal install package and ensure installations proceeed as usual.
So, if somone can provide a complete list of no-longer included packages that would be super helpfui so we can all adjust as needed.
https://web.archive.org/web/20190722121302/https://www.archlinux.org/groups/...
One dependency that exists is netctl and dialog. You can't use wifi-menu unless dialog is pre-installed and wifi-menu if I'm not much mistaken is a part of netctl. --
On Wed, 9 Oct 2019 12:13:28 -0400 Jude DaShiell <jdashiel@panix.com> wrote:
One dependency that exists is netctl and dialog. You can't use wifi-menu unless dialog is pre-installed and wifi-menu if I'm not much mistaken is a part of netctl.
--
Optional dependencies are a standard part of Arch.
participants (30)
-
Andy Pieters
-
Bruno Pagani
-
Dan Sommers
-
David C. Rankin
-
Doug Newgard
-
Eli Schwartz
-
Filipe Laíns
-
Genes Lists
-
Giancarlo Razzolini
-
Greg Land
-
Guus Snijders
-
Jonathan Steel
-
Jude DaShiell
-
mar77i＠protonmail.ch
-
Marc Ranolfi
-
Mike Cloaked
-
Mohammadreza Abdollahzadeh
-
Nero Claudius Drusus
-
Paul Stoetzer
-
pete
-
Ralf Mardorf
-
Ralph Corderoy
-
Ram Kumar
-
sL1pKn07 SpinFlo
-
Storm Dragon
-
Tinu Weber
-
Tomasz Kramkowski
-
William Bevans
-
Yaro Kasear
-
Óscar García Amor