[arch-dev-public] Proposal: minimal base system
# Proposal There is no strict definition of what a minimal Arch Linux system installation must contain. However in reality we mostly don’t add any packages that are in the base group as a dependency to other packages, which basically makes it a hard requirement. The current way of defining a minimal system via a group is non-optimal for the following reasons: - A group can’t enforce installation of packages when being extended or modified - The current base group contains lots of unneeded packages - Manually getting rid of some of the packages may result in broken deps To overcome the disadvantages, a better way to handle a strictly defined set would be a simple virtual base-system package that depends on the bare minimum of what we define as given and required. This virtual package can be changed/extended and every installation will pull it in during the next system upgrade. Everything that won’t be part of base-system needs to be added as a dependency to all requiring packages; alternatively don't omit any first level runtime dependencies at all. This package should only depend on strictly required explicit packages to get a working minimal Arch Linux system. The proposed end result is: - base: convenient helper group for quickly getting a working system when installing, must include the new base-system package - base-system: package defining the minimum dependencies for a working base runtime Possible candidates for the virtual package: #### Base requirements: - filesystem - gcc-libs - glibc - bash - coreutils #### Distro requirements: - licenses - pacman - systemd #### Some POSIX tools - coreutils - file - findutils - gawk - grep - procps-ng - sed - tar - gettext - pciutils - psmisc - shadow - util-linux - bzip2 - gzip - xz #### Some networking tools - iputils - iproute2 ## Alternative Another approach would be, assuming we want to properly support tiny containers, to reduce the above list even further to a bare minimum of running pacman and not omit any further 1st level runtime dependencies in our packages. ## Short summary Required: - Use a virtual package instead of a group for the bare minimum Option 1: - Define a base-system virtual package as a required set of packages containing something like a POSIX interactive runtime environment Option 2: - Reduce the set even further to aid tiny containers and don't omit any other 1st level runtime dependency in packages - We could additionally still have a smaller set for a POSIX interactive runtime environment for convenience PS: Please focus on the abstract before bikeshedding whether single packages should or should not be added cheers, Levente
On 1/21/19 5:03 PM, Levente Polyak via arch-dev-public wrote:
# Proposal
There is no strict definition of what a minimal Arch Linux system installation must contain. However in reality we mostly don’t add any packages that are in the base group as a dependency to other packages, which basically makes it a hard requirement.
The current way of defining a minimal system via a group is non-optimal for the following reasons:
- A group can’t enforce installation of packages when being extended or modified - The current base group contains lots of unneeded packages - Manually getting rid of some of the packages may result in broken deps
To overcome the disadvantages, a better way to handle a strictly defined set would be a simple virtual base-system package that depends on the bare minimum of what we define as given and required. This virtual package can be changed/extended and every installation will pull it in during the next system upgrade.
Everything that won’t be part of base-system needs to be added as a dependency to all requiring packages; alternatively don't omit any first level runtime dependencies at all.
This package should only depend on strictly required explicit packages to get a working minimal Arch Linux system.
The proposed end result is: - base: convenient helper group for quickly getting a working system when installing, must include the new base-system package - base-system: package defining the minimum dependencies for a working base runtime
\o/ finally proposing something which may in practice clear up our horrible confusion.
Possible candidates for the virtual package:
#### Base requirements: - filesystem - gcc-libs - glibc - bash - coreutils
#### Distro requirements: - licenses - pacman - systemd
#### Some POSIX tools - coreutils - file - findutils - gawk - grep - procps-ng - sed - tar - gettext - pciutils - psmisc - shadow - util-linux - bzip2 - gzip - xz
#### Some networking tools - iputils - iproute2
## Alternative
Another approach would be, assuming we want to properly support tiny containers, to reduce the above list even further to a bare minimum of running pacman and not omit any further 1st level runtime dependencies in our packages.
For the record: if containers really want to do strange things and possibly break any script that is being run, I'm of the opinion that they are free to do their own by manually scripting pacstrap to only install the packages they want, but I don't expect the users to call that Arch and expect support if the sky falls because their system users and script dependencies disappear. (systemd is needed for sysusers/tmpfiles at minimum, and mostly other than that we're targeting a basically POSIX scripting environment plus the package manager)
## Short summary
Required: - Use a virtual package instead of a group for the bare minimum
Option 1: - Define a base-system virtual package as a required set of packages containing something like a POSIX interactive runtime environment
Option 2: - Reduce the set even further to aid tiny containers and don't omit any other 1st level runtime dependency in packages - We could additionally still have a smaller set for a POSIX interactive runtime environment for convenience
PS: Please focus on the abstract before bikeshedding whether single packages should or should not be added
cheers, Levente
-- Eli Schwartz Bug Wrangler and Trusted User
On 22/1/19 8:03 am, Levente Polyak via arch-dev-public wrote:
Everything that won’t be part of base-system needs to be added as a dependency to all requiring packages; alternatively don't omit any first level runtime dependencies at all.
This package should only depend on strictly required explicit packages to get a working minimal Arch Linux system.
The proposed end result is: - base: convenient helper group for quickly getting a working system when installing, must include the new base-system package - base-system: package defining the minimum dependencies for a working base runtime
I think the proposal is OK. I'm not comfortable with our line about base group packages being required given how many of them I don't have installed. However... I don't like idea of the base group and base-system package existing together. You definition of what base-system should be is much the same as what the base group was defined to be. What package justifies itself in the base group, but would not be in base-system? It seems we would have two very similar things where one would do. Allan
Le 22/01/2019 à 00:23, Allan McRae via arch-dev-public a écrit :
Everything that won’t be part of base-system needs to be added as a dependency to all requiring packages; alternatively don't omit any first level runtime dependencies at all.
This package should only depend on strictly required explicit packages to get a working minimal Arch Linux system.
The proposed end result is: - base: convenient helper group for quickly getting a working system when installing, must include the new base-system package - base-system: package defining the minimum dependencies for a working base runtime I think the proposal is OK. I'm not comfortable with our line about
On 22/1/19 8:03 am, Levente Polyak via arch-dev-public wrote: base group packages being required given how many of them I don't have installed.
However... I don't like idea of the base group and base-system package existing together. You definition of what base-system should be is much the same as what the base group was defined to be. What package justifies itself in the base group, but would not be in base-system? It seems we would have two very similar things where one would do.
Allan
In the proposal, base would really just be a convenient helper for e.g. beginners installing their system, so they could get all tools that are often used during install (e.g. cryptsetup, lvm2, various FS/network tools, etc.) or (POSIX) tools people coming from other distros would expect to be here by default (man pages, nano/vi…) but that are interactive ones and thus not really required for operating. Anyone knowing their stuff could just install base-system + what they actually need (e.g., I would install cryptsetup and vim, and not care about netctl, xfsprogs or lvm2). Does that make sense to you? Bruno
Em janeiro 21, 2019 20:03 Levente Polyak via arch-dev-public escreveu:
# Proposal
There is no strict definition of what a minimal Arch Linux system installation must contain. However in reality we mostly don’t add any packages that are in the base group as a dependency to other packages, which basically makes it a hard requirement.
First of all, I'm glad you're bringing this up, even if the last two times this was brought up, either it ended on bikeshedding or the thread simply died. We have been recommending users to install base at least since 2007. I went through the wiki history and found the entry when we started telling users to install base. It is on another thread about this "base-system" group. I don't want to dig it up.
To overcome the disadvantages, a better way to handle a strictly defined set would be a simple virtual base-system package that depends on the bare minimum of what we define as given and required. This virtual package can be changed/extended and every installation will pull it in during the next system upgrade.
base-system with the bare minimal is the way to go, I agree with this. With strict dependency between packages. No more "assuming" base is installed.
Everything that won’t be part of base-system needs to be added as a dependency to all requiring packages; alternatively don't omit any first level runtime dependencies at all.
This package should only depend on strictly required explicit packages to get a working minimal Arch Linux system.
The proposed end result is: - base: convenient helper group for quickly getting a working system when installing, must include the new base-system package - base-system: package defining the minimum dependencies for a working base runtime
Possible candidates for the virtual package:
#### Base requirements: - filesystem - gcc-libs - glibc - bash - coreutils
#### Distro requirements: - licenses - pacman - systemd
#### Some POSIX tools - coreutils - file - findutils - gawk - grep - procps-ng - sed - tar - gettext - pciutils - psmisc - shadow - util-linux - bzip2 - gzip - xz
#### Some networking tools - iputils - iproute2
I agree with this package list. It's missing mkinitcpio though. Hopefully this time we'll get this moving along. Count me in for testing. Regards, Giancarlo Razzolini
On 1/21/19 6:53 PM, Giancarlo Razzolini via arch-dev-public wrote:
I agree with this package list. It's missing mkinitcpio though.
No it is not, mkinitcpio is definitively not needed. It's only required in order to execute the pacman hooks for a linux kernel package (or do so manually). And core/linux is not required to use archlinux, although it is required to boot it on bare metal. The most recent version of my PKGBUILD draft for this "base-system" PKGBUILD (which I shared with Levente during the planning stages of this proposal) can be found here: https://paste.xinu.at/KZmYqQwIO/ I've actually listed optdepends=('linux: bare metal support') And IMO that is exactly where mkinitcpio belongs -- as a hard dependency for any package which intends to implement a kernel for booting to bare metal. -- Eli Schwartz Bug Wrangler and Trusted User
On 22/1/19 9:41 am, Bruno Pagani wrote:
Le 22/01/2019 à 00:23, Allan McRae via arch-dev-public a écrit :
Everything that won’t be part of base-system needs to be added as a dependency to all requiring packages; alternatively don't omit any first level runtime dependencies at all.
This package should only depend on strictly required explicit packages to get a working minimal Arch Linux system.
The proposed end result is: - base: convenient helper group for quickly getting a working system when installing, must include the new base-system package - base-system: package defining the minimum dependencies for a working base runtime I think the proposal is OK. I'm not comfortable with our line about
On 22/1/19 8:03 am, Levente Polyak via arch-dev-public wrote: base group packages being required given how many of them I don't have installed.
However... I don't like idea of the base group and base-system package existing together. You definition of what base-system should be is much the same as what the base group was defined to be. What package justifies itself in the base group, but would not be in base-system? It seems we would have two very similar things where one would do.
Allan
In the proposal, base would really just be a convenient helper for e.g. beginners installing their system, so they could get all tools that are often used during install (e.g. cryptsetup, lvm2, various FS/network tools, etc.) or (POSIX) tools people coming from other distros would expect to be here by default (man pages, nano/vi…) but that are interactive ones and thus not really required for operating.
Anyone knowing their stuff could just install base-system + what they actually need (e.g., I would install cryptsetup and vim, and not care about netctl, xfsprogs or lvm2).
"Anyone knowing their stuff" is the essentially the stated Arch target audience. So, the definitions of the sets of packages are: base-system - essential packages we assume everyone has installed (previous definition of base...) base group - base-system plus other packages some people probably want/expect and support packages for filesystem types most people don't actually need. Maybe slightly facetious on that last one, but I don't see a clear need for the base group once base-system exists. Allan
On Mon, Jan 21, 2019 at 06:58:54PM -0500, Eli Schwartz via arch-dev-public wrote:
The most recent version of my PKGBUILD draft for this "base-system" PKGBUILD (which I shared with Levente during the planning stages of this proposal) can be found here: https://paste.xinu.at/KZmYqQwIO/
FYI that package is a bit outdated as we removed `diffutils` and `inetutils`. Along with not considering interactive packages while partially rewriting the list today. -- Morten Linderud PGP: 9C02FF419FECBE16
[2019-01-21 18:58:54 -0500] Eli Schwartz via arch-dev-public:
On 1/21/19 6:53 PM, Giancarlo Razzolini via arch-dev-public wrote:
I agree with this package list. It's missing mkinitcpio though.
No it is not, mkinitcpio is definitively not needed.
It's only required in order to execute the pacman hooks for a linux kernel package (or do so manually). And core/linux is not required to use archlinux, although it is required to boot it on bare metal.
The most recent version of my PKGBUILD draft for this "base-system" PKGBUILD (which I shared with Levente during the planning stages of this proposal) can be found here: https://paste.xinu.at/KZmYqQwIO/
That sounds good to me but I think the name of this new virtual group needs to really emphasize its difference to the current (and future) base group more clearly. Perhaps something like `minimal-system` or anything else somebody clever than me can think of, so long as it does not include the words `base` or `core` to avoid confusion. Apart from this important bikeshedding issue, I'm all in favor of this. Cheers. -- Gaetan
Le 22/01/2019 à 03:25, Gaetan Bisson via arch-dev-public a écrit :
On 1/21/19 6:53 PM, Giancarlo Razzolini via arch-dev-public wrote:
I agree with this package list. It's missing mkinitcpio though. No it is not, mkinitcpio is definitively not needed.
It's only required in order to execute the pacman hooks for a linux kernel package (or do so manually). And core/linux is not required to use archlinux, although it is required to boot it on bare metal.
The most recent version of my PKGBUILD draft for this "base-system" PKGBUILD (which I shared with Levente during the planning stages of this proposal) can be found here: https://paste.xinu.at/KZmYqQwIO/ That sounds good to me but I think the name of this new virtual group needs to really emphasize its difference to the current (and future)
[2019-01-21 18:58:54 -0500] Eli Schwartz via arch-dev-public: base group more clearly. Perhaps something like `minimal-system` or anything else somebody clever than me can think of, so long as it does not include the words `base` or `core` to avoid confusion.
Apart from this important bikeshedding issue, I'm all in favor of this.
Cheers.
What about `arch-system` instead then? Bruno
On 22/01/2019 00.23, Allan McRae via arch-dev-public wrote:
On 22/1/19 8:03 am, Levente Polyak via arch-dev-public wrote:
Everything that won’t be part of base-system needs to be added as a dependency to all requiring packages; alternatively don't omit any first level runtime dependencies at all.
This package should only depend on strictly required explicit packages to get a working minimal Arch Linux system.
The proposed end result is: - base: convenient helper group for quickly getting a working system when installing, must include the new base-system package - base-system: package defining the minimum dependencies for a working base runtime
I think the proposal is OK. I'm not comfortable with our line about base group packages being required given how many of them I don't have installed.
However... I don't like idea of the base group and base-system package existing together. You definition of what base-system should be is much the same as what the base group was defined to be. What package justifies itself in the base group, but would not be in base-system? It seems we would have two very similar things where one would do.
Allan
Maybe it's my reading comprehension failing me but I also don't really understand the point of base-system, or rather why the base group can't be simply stripped down to Levente's list. Bartłomiej
On 2019/01/22 7:26, Eli Schwartz via arch-dev-public wrote:
On 1/21/19 5:03 PM, Levente Polyak via arch-dev-public wrote:
# Proposal
The proposed end result is: - base: convenient helper group for quickly getting a working system when installing, must include the new base-system package - base-system: package defining the minimum dependencies for a working base runtime
#### Some networking tools - iputils - iproute2
Therefore if we define the "base-system" from the point of packging,
Great to see this idea is coming back. The definition by description is somewhat vague, so I think a definition from a practical point may clear up some details. Currently the "base" group serves at least 2 purposes for us: 1. A short-hand for new users to pacstrap a new Arch Linux. 2. A base chroot environment for devtools/makechrootpkg to prepare packaging. I would like to suggest to keep "base" group for the 1st purpose, and make the new "base-system" (or whatever name) virtual/meta package to serve for the 2nd purpose. Currently, devtools/makechrootpkg will install "base" group for the packaging environment, which essentially makes "base" group as implicit depends for all packages (and "base-devel" as implicit makedepends). A huge packaging environment may make the undergoing reproduciblity efforts more difficult. So it will be better if we can shrink the packaging environment to only contains essential things. there is no need to keep networking tools in it. Also if we have "base-system" for packaging, we may afford to include more useful things (WiFi tools like wpa_supplicant, dialog, wpa_actiond is what come to my mind) in "base" group for new users. Lastly, I want to suggest "essential" instead of "base-system" as the pkgname. But my English is poor so this suggestion is weaker than optdepends ... Best Hope~ -- Jiachen YANG (farseerfc)
On Wed, 23 Jan 2019 00:09:32 +0900
Jiachen YANG via arch-dev-public
Currently the "base" group serves at least 2 purposes for us: ... 2. A base chroot environment for devtools/makechrootpkg to prepare packaging. ... Currently, devtools/makechrootpkg will install "base" group for the packaging environment, which essentially makes "base" group as implicit depends for all packages (and "base-devel" as implicit makedepends).
This is simply not true. devtools/makechrootpkg installs base-devel only, not base, so it's totally irrelevant to this discussion. Doug
On 2019/01/23 0:26, Doug Newgard via arch-dev-public wrote:
This is simply not true. devtools/makechrootpkg installs base-devel only, not base, so it's totally irrelevant to this discussion.
Doug
Oh I am sorry for the misinformation. -- Jiachen YANG (farseerfc)
Le 22/01/2019 à 00:59, Allan McRae a écrit :
On 22/1/19 9:41 am, Bruno Pagani wrote:
Le 22/01/2019 à 00:23, Allan McRae via arch-dev-public a écrit :
Everything that won’t be part of base-system needs to be added as a dependency to all requiring packages; alternatively don't omit any first level runtime dependencies at all.
This package should only depend on strictly required explicit packages to get a working minimal Arch Linux system.
The proposed end result is: - base: convenient helper group for quickly getting a working system when installing, must include the new base-system package - base-system: package defining the minimum dependencies for a working base runtime I think the proposal is OK. I'm not comfortable with our line about
On 22/1/19 8:03 am, Levente Polyak via arch-dev-public wrote: base group packages being required given how many of them I don't have installed.
However... I don't like idea of the base group and base-system package existing together. You definition of what base-system should be is much the same as what the base group was defined to be. What package justifies itself in the base group, but would not be in base-system? It seems we would have two very similar things where one would do.
Allan In the proposal, base would really just be a convenient helper for e.g. beginners installing their system, so they could get all tools that are often used during install (e.g. cryptsetup, lvm2, various FS/network tools, etc.) or (POSIX) tools people coming from other distros would expect to be here by default (man pages, nano/vi…) but that are interactive ones and thus not really required for operating.
Anyone knowing their stuff could just install base-system + what they actually need (e.g., I would install cryptsetup and vim, and not care about netctl, xfsprogs or lvm2). "Anyone knowing their stuff" is the essentially the stated Arch target audience.
So apparently we did not answer all concerns here. I don’t expect Arch users to know thing so well that they know exactly what tools are in which packages when they install Arch for the first time. I think we should not mistake Arch Power Users, people that have a level of knowledge above Arch Users, that are just generic Linux Power Users.
So, the definitions of the sets of packages are:
base-system - essential packages we assume everyone has installed (previous definition of base...)
To be clearer, the new proposition would be to call this arch-system to avoid confusion with base. However, note that this “previous definition of base” is definitively not that clear: when I installed Arch, I read things as “base is a convenient helper to get almost every standard tools you could need to do your install”.
base group - base-system plus other packages some people probably want/expect and support packages for filesystem types most people don't actually need. For me, base will be what it has ever been: a fast way to get started as an Arch beginner. Maybe slightly facetious on that last one, but I don't see a clear need for the base group once base-system exists.
Because, as an Arch dev, you definitively qualify as an Arch Power Users. I wouldn’t use base either for myself, but I firmly believe most Arch beginners would. Does that make sense to you, or do you still think every new Arch User should already know exactly what is required to get started? Regards, Bruno
Le 22/01/2019 à 14:44, Bartłomiej Piotrowski via arch-dev-public a écrit :
On 22/01/2019 00.23, Allan McRae via arch-dev-public wrote:
Everything that won’t be part of base-system needs to be added as a dependency to all requiring packages; alternatively don't omit any first level runtime dependencies at all.
This package should only depend on strictly required explicit packages to get a working minimal Arch Linux system.
The proposed end result is: - base: convenient helper group for quickly getting a working system when installing, must include the new base-system package - base-system: package defining the minimum dependencies for a working base runtime I think the proposal is OK. I'm not comfortable with our line about
On 22/1/19 8:03 am, Levente Polyak via arch-dev-public wrote: base group packages being required given how many of them I don't have installed.
However... I don't like idea of the base group and base-system package existing together. You definition of what base-system should be is much the same as what the base group was defined to be. What package justifies itself in the base group, but would not be in base-system? It seems we would have two very similar things where one would do.
Allan
Maybe it's my reading comprehension failing me but I also don't really understand the point of base-system, or rather why the base group can't be simply stripped down to Levente's list.
So they are two aspect to that: 1. From a technical point of view, a group is less convenient than a metapackage if we ever intend to modify the list. So just trimming down the base group wouldn’t do it. 2. Regarding what is more likely the real content of your message, they are already some people that never considered the base group as what must be installed (especially since a group cannot enforce that conveniently because of 1), but as a convenient helper for Arch beginners doing their first install. I, like other, still think the base group could keep this value, while the base-system/arch-system package would fill the role other people intended for base, but in better ways. I, at a personal level, don’t care about a base group that I wouldn’t use at all (just like you or likely any other Arch staff for that regard). But I have to think on a larger scope, and if having this package helps new users getting started with Arch, then I think it’s worth having it. Not because I want Arch to be used by the largest number of people, but because I believe that some of those people will be tomorrow TUs and devs, after becoming more acquainted with Linux and Arch internals thanks to their use of a distro that try to teach them about all this. Would the absence of a base group be a too high barrier for some? I don’t know. Maybe not, especially since our wiki is amazing and maybe most installation cases requiring a non base-system/arch-system tool that are currently in base already tells to install this tool. Or maybe not, because those wiki page currently assume that people either have base installed, or know exactly what they are doing? Now my question to both you and Allan (or other that might have the same concern): you seem to agree with our base-system/arch-system proposal, but are wondering about the current base group. Would you actually be bothered by the existence of this group in addition of the *-system/minimal/whatever metapackage and if so why (for instance Gaetan had a relevant concern about the naming, hence the idea or arch-system/minimal —renaming the base group could be doable to though, but would require more work), or is it just that you don’t see a point in keeping it, so why not remove it altogether? In any case, I hope we can address your concerns and move forward with this proposal. Regards, Bruno
On 5/2/19 9:06 pm, Bruno Pagani wrote:
Le 22/01/2019 à 00:59, Allan McRae a écrit :
On 22/1/19 9:41 am, Bruno Pagani wrote:
Le 22/01/2019 à 00:23, Allan McRae via arch-dev-public a écrit :
Everything that won’t be part of base-system needs to be added as a dependency to all requiring packages; alternatively don't omit any first level runtime dependencies at all.
This package should only depend on strictly required explicit packages to get a working minimal Arch Linux system.
The proposed end result is: - base: convenient helper group for quickly getting a working system when installing, must include the new base-system package - base-system: package defining the minimum dependencies for a working base runtime I think the proposal is OK. I'm not comfortable with our line about
On 22/1/19 8:03 am, Levente Polyak via arch-dev-public wrote: base group packages being required given how many of them I don't have installed.
However... I don't like idea of the base group and base-system package existing together. You definition of what base-system should be is much the same as what the base group was defined to be. What package justifies itself in the base group, but would not be in base-system? It seems we would have two very similar things where one would do.
Allan In the proposal, base would really just be a convenient helper for e.g. beginners installing their system, so they could get all tools that are often used during install (e.g. cryptsetup, lvm2, various FS/network tools, etc.) or (POSIX) tools people coming from other distros would expect to be here by default (man pages, nano/vi…) but that are interactive ones and thus not really required for operating.
Anyone knowing their stuff could just install base-system + what they actually need (e.g., I would install cryptsetup and vim, and not care about netctl, xfsprogs or lvm2). "Anyone knowing their stuff" is the essentially the stated Arch target audience.
So apparently we did not answer all concerns here. I don’t expect Arch users to know thing so well that they know exactly what tools are in which packages when they install Arch for the first time. I think we should not mistake Arch Power Users, people that have a level of knowledge above Arch Users, that are just generic Linux Power Users.
So, the definitions of the sets of packages are:
base-system - essential packages we assume everyone has installed (previous definition of base...)
To be clearer, the new proposition would be to call this arch-system to avoid confusion with base. However, note that this “previous definition of base” is definitively not that clear: when I installed Arch, I read things as “base is a convenient helper to get almost every standard tools you could need to do your install”.
base group - base-system plus other packages some people probably want/expect and support packages for filesystem types most people don't actually need. For me, base will be what it has ever been: a fast way to get started as an Arch beginner. Maybe slightly facetious on that last one, but I don't see a clear need for the base group once base-system exists.
Because, as an Arch dev, you definitively qualify as an Arch Power Users. I wouldn’t use base either for myself, but I firmly believe most Arch beginners would.
Does that make sense to you, or do you still think every new Arch User should already know exactly what is required to get started?
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). 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. A
Le 05/02/2019 à 12:54, Allan McRae a écrit :
On 5/2/19 9:06 pm, Bruno Pagani wrote:
Le 22/01/2019 à 00:59, Allan McRae a écrit :
On 22/1/19 9:41 am, Bruno Pagani wrote:
Le 22/01/2019 à 00:23, Allan McRae via arch-dev-public a écrit :
Everything that won’t be part of base-system needs to be added as a dependency to all requiring packages; alternatively don't omit any first level runtime dependencies at all.
This package should only depend on strictly required explicit packages to get a working minimal Arch Linux system.
The proposed end result is: - base: convenient helper group for quickly getting a working system when installing, must include the new base-system package - base-system: package defining the minimum dependencies for a working base runtime I think the proposal is OK. I'm not comfortable with our line about
On 22/1/19 8:03 am, Levente Polyak via arch-dev-public wrote: base group packages being required given how many of them I don't have installed.
However... I don't like idea of the base group and base-system package existing together. You definition of what base-system should be is much the same as what the base group was defined to be. What package justifies itself in the base group, but would not be in base-system? It seems we would have two very similar things where one would do.
Allan In the proposal, base would really just be a convenient helper for e.g. beginners installing their system, so they could get all tools that are often used during install (e.g. cryptsetup, lvm2, various FS/network tools, etc.) or (POSIX) tools people coming from other distros would expect to be here by default (man pages, nano/vi…) but that are interactive ones and thus not really required for operating.
Anyone knowing their stuff could just install base-system + what they actually need (e.g., I would install cryptsetup and vim, and not care about netctl, xfsprogs or lvm2). "Anyone knowing their stuff" is the essentially the stated Arch target audience. So apparently we did not answer all concerns here. I don’t expect Arch users to know thing so well that they know exactly what tools are in which packages when they install Arch for the first time. I think we should not mistake Arch Power Users, people that have a level of knowledge above Arch Users, that are just generic Linux Power Users.
So, the definitions of the sets of packages are:
base-system - essential packages we assume everyone has installed (previous definition of base...) To be clearer, the new proposition would be to call this arch-system to avoid confusion with base. However, note that this “previous definition of base” is definitively not that clear: when I installed Arch, I read things as “base is a convenient helper to get almost every standard tools you could need to do your install”.
base group - base-system plus other packages some people probably want/expect and support packages for filesystem types most people don't actually need. For me, base will be what it has ever been: a fast way to get started as an Arch beginner. Maybe slightly facetious on that last one, but I don't see a clear need for the base group once base-system exists. Because, as an Arch dev, you definitively qualify as an Arch Power Users. I wouldn’t use base either for myself, but I firmly believe most Arch beginners would.
Does that make sense to you, or do you still think every new Arch User should already know exactly what is required to get started?
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.
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? Or put it yet another way: outside of this base group, does our proposal of a minimal metapackage suits you? If so, why does it matter to you that there is also a base group, provided the name is not subject to confusion, that has this metapackage plus other tools (that e.g. people coming from random other distro would expect to have at hand from the start), knowing that you would likely have almost no interactions with this group? If not, then I’m even more importantly waiting for your comments. I’m genuinely interested in your point of view on those questions, maybe they are some inconveniences I don’t see but you do. Regards, Bruno
On 5/2/19 11:38 pm, Bruno Pagani wrote:
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.
If only the wiki wasn't a static document, and could be updated after any change was made... Even then I am fairly sure people wanting to set-up LVM can install the lvm package. But I see "competent Linux user" has been removed from the front page, so maybe we target idiots these days.
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?
Or put it yet another way: outside of this base group, does our proposal of a minimal metapackage suits you? If so, why does it matter to you that there is also a base group, provided the name is not subject to confusion, that has this metapackage plus other tools (that e.g. people coming from random other distro would expect to have at hand from the start), knowing that you would likely have almost no interactions with this group? If not, then I’m even more importantly waiting for your comments.
I don't object to redefining the minimal set of packages we expect installed and making it a metapackage. Currently base is bloated, and a metapackage makes some sense. archlinux-system - minimal set of packages base-devel - collection of utilities most people expect installed So where does that leave base? base - a smaller collection of utilities most people expect installed I see redundancy being created. That is what I object to. Allan
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. Cheers. -- Gaetan
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
Le 06/02/2019 à 00:26, Eli Schwartz via arch-dev-public a écrit :
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.
Just in case it wasn’t clear, my answer would have been mostly the same as Eli’s. So, Gaetan, Allan and Bartłomiej (or anyone else for that matter), do you have further comments/questions regarding this, does the existence of the base group alongside the arch/minimal-system now makes sense or would you still prefer to go without it? Regards, Bruno
[2019-02-12 16:40:08 +0100] Bruno Pagani via arch-dev-public:
Just in case it wasn’t clear, my answer would have been mostly the same as Eli’s.
So, Gaetan, Allan and Bartłomiej (or anyone else for that matter), do you have further comments/questions regarding this, does the existence of the base group alongside the arch/minimal-system now makes sense or would you still prefer to go without it?
Allan and I have both stated that we don't want to introduce a new group since we believe it would be highly redundant with base. Nothing new has been said since our last messages except Eli's post which argues that the base group is largely inadequate in its current state. This further supports our proposal that base should be improved instead of introducing a new group. So I really don't see what arguments could have changed our minds... It's also strange to me how you can concur with Eli's post without agreeing with our conclusions. To go forward I suggest you propose a clear definition of the perfect "minimal system" group you'd want to have, along with a proposed list of packages. When consensus is reached, we adopt this list of packages for base and put this definition on the wiki. Cheers. -- Gaetan
On 2/12/19 7:16 PM, Gaetan Bisson via arch-dev-public wrote:
[2019-02-12 16:40:08 +0100] Bruno Pagani via arch-dev-public:
Just in case it wasn’t clear, my answer would have been mostly the same as Eli’s.
So, Gaetan, Allan and Bartłomiej (or anyone else for that matter), do you have further comments/questions regarding this, does the existence of the base group alongside the arch/minimal-system now makes sense or would you still prefer to go without it?
Allan and I have both stated that we don't want to introduce a new group since we believe it would be highly redundant with base.
Nothing new has been said since our last messages except Eli's post which argues that the base group is largely inadequate in its current state. This further supports our proposal that base should be improved instead of introducing a new group.
So I really don't see what arguments could have changed our minds... It's also strange to me how you can concur with Eli's post without agreeing with our conclusions.
To go forward I suggest you propose a clear definition of the perfect "minimal system" group you'd want to have, along with a proposed list of packages. When consensus is reached, we adopt this list of packages for base and put this definition on the wiki.
Cheers.
To make it as short as possible, the idea is not just to strip down the base group further but primarily to not use a group in the first place. It should be replaced with something that is consistent within itself over the whole lifetime of the system. Groups are the wrong tool for such a set: you explicitly install all those packages so they won't automatically be mark as not-required anymore once removed from that group, as well as new additions are not consistent during the lifetime of the system. Cheers.
On 13/2/19 8:17 am, Levente Polyak via arch-dev-public wrote:
On 2/12/19 7:16 PM, Gaetan Bisson via arch-dev-public wrote:
[2019-02-12 16:40:08 +0100] Bruno Pagani via arch-dev-public:
Just in case it wasn’t clear, my answer would have been mostly the same as Eli’s.
So, Gaetan, Allan and Bartłomiej (or anyone else for that matter), do you have further comments/questions regarding this, does the existence of the base group alongside the arch/minimal-system now makes sense or would you still prefer to go without it?
Allan and I have both stated that we don't want to introduce a new group since we believe it would be highly redundant with base.
Nothing new has been said since our last messages except Eli's post which argues that the base group is largely inadequate in its current state. This further supports our proposal that base should be improved instead of introducing a new group.
So I really don't see what arguments could have changed our minds... It's also strange to me how you can concur with Eli's post without agreeing with our conclusions.
To go forward I suggest you propose a clear definition of the perfect "minimal system" group you'd want to have, along with a proposed list of packages. When consensus is reached, we adopt this list of packages for base and put this definition on the wiki.
Cheers.
To make it as short as possible, the idea is not just to strip down the base group further but primarily to not use a group in the first place. It should be replaced with something that is consistent within itself over the whole lifetime of the system. Groups are the wrong tool for such a set: you explicitly install all those packages so they won't automatically be mark as not-required anymore once removed from that group, as well as new additions are not consistent during the lifetime of the system.
We are clear about that. Call it a group or metapackage or whatever, the objection is having the current base and the new "group" at the same time. A
On 2/12/19 11:55 PM, Allan McRae wrote:
On 13/2/19 8:17 am, Levente Polyak via arch-dev-public wrote:
On 2/12/19 7:16 PM, Gaetan Bisson via arch-dev-public wrote:
[2019-02-12 16:40:08 +0100] Bruno Pagani via arch-dev-public:
Just in case it wasn’t clear, my answer would have been mostly the same as Eli’s.
So, Gaetan, Allan and Bartłomiej (or anyone else for that matter), do you have further comments/questions regarding this, does the existence of the base group alongside the arch/minimal-system now makes sense or would you still prefer to go without it?
Allan and I have both stated that we don't want to introduce a new group since we believe it would be highly redundant with base.
Nothing new has been said since our last messages except Eli's post which argues that the base group is largely inadequate in its current state. This further supports our proposal that base should be improved instead of introducing a new group.
So I really don't see what arguments could have changed our minds... It's also strange to me how you can concur with Eli's post without agreeing with our conclusions.
To go forward I suggest you propose a clear definition of the perfect "minimal system" group you'd want to have, along with a proposed list of packages. When consensus is reached, we adopt this list of packages for base and put this definition on the wiki.
Cheers.
To make it as short as possible, the idea is not just to strip down the base group further but primarily to not use a group in the first place. It should be replaced with something that is consistent within itself over the whole lifetime of the system. Groups are the wrong tool for such a set: you explicitly install all those packages so they won't automatically be mark as not-required anymore once removed from that group, as well as new additions are not consistent during the lifetime of the system.
We are clear about that. Call it a group or metapackage or whatever, the objection is having the current base and the new "group" at the same time.
A
Sure, then we are on the same page now. The wording here is just important as, at least for me, it gets totally confusing what we are exactly talking about if we start mixing metapackages and groups while discussing possible steps. Personally I'm totally fine with just nuking the rest of the group out of orbit and possibly extend the wiki with some of those recommended packages. I totally understand the fear of introducing "confusion and duplication" so I'm fine with just having a proper defined set and nothing further. Cheers, Levente
Le 12/02/2019 à 19:16, Gaetan Bisson a écrit :
[2019-02-12 16:40:08 +0100] Bruno Pagani via arch-dev-public:
Just in case it wasn’t clear, my answer would have been mostly the same as Eli’s.
So, Gaetan, Allan and Bartłomiej (or anyone else for that matter), do you have further comments/questions regarding this, does the existence of the base group alongside the arch/minimal-system now makes sense or would you still prefer to go without it? Allan and I have both stated that we don't want to introduce a new group since we believe it would be highly redundant with base.
Nothing new has been said since our last messages except Eli's post which argues that the base group is largely inadequate in its current state. This further supports our proposal that base should be improved instead of introducing a new group.
So I really don't see what arguments could have changed our minds... It's also strange to me how you can concur with Eli's post without agreeing with our conclusions.
We did not read Eli the same way apparently. To me, Eli was answering what should be in the base group but not in the arch/minimal-system metapackage. And then I agree with what he listed. So my question is: given what we propose for the minimal metapackage (see below) and what Eli listed as being useful in a base group when seeing this one as a convenient helper, do you still think that keeping the base group is problematic? If so, then I propose we just move on with removing the base group and implementing the metapackage, I care much more for getting this one set up than for keeping base.
To go forward I suggest you propose a clear definition of the perfect "minimal system" group you'd want to have, along with a proposed list of packages.
The list is available in the very first post (by Levente) of this thread. ;)
When consensus is reached, we adopt this list of packages for base and put this definition on the wiki.
As later clarified by Levente, not for base, but for a new metapackage with a different name to avoid confusion (whether we keep the base group or not I think). Regards, Bruno
[2019-02-13 08:55:27 +1000] Allan McRae via arch-dev-public:
On 13/2/19 8:17 am, Levente Polyak via arch-dev-public wrote:
On 2/12/19 7:16 PM, Gaetan Bisson via arch-dev-public wrote:
[2019-02-12 16:40:08 +0100] Bruno Pagani via arch-dev-public:
Just in case it wasn’t clear, my answer would have been mostly the same as Eli’s.
So, Gaetan, Allan and Bartłomiej (or anyone else for that matter), do you have further comments/questions regarding this, does the existence of the base group alongside the arch/minimal-system now makes sense or would you still prefer to go without it?
Allan and I have both stated that we don't want to introduce a new group since we believe it would be highly redundant with base.
Nothing new has been said since our last messages except Eli's post which argues that the base group is largely inadequate in its current state. This further supports our proposal that base should be improved instead of introducing a new group.
So I really don't see what arguments could have changed our minds... It's also strange to me how you can concur with Eli's post without agreeing with our conclusions.
To go forward I suggest you propose a clear definition of the perfect "minimal system" group you'd want to have, along with a proposed list of packages. When consensus is reached, we adopt this list of packages for base and put this definition on the wiki.
Cheers.
To make it as short as possible, the idea is not just to strip down the base group further but primarily to not use a group in the first place. It should be replaced with something that is consistent within itself over the whole lifetime of the system. Groups are the wrong tool for such a set: you explicitly install all those packages so they won't automatically be mark as not-required anymore once removed from that group, as well as new additions are not consistent during the lifetime of the system.
We are clear about that. Call it a group or metapackage or whatever, the objection is having the current base and the new "group" at the same time.
My thoughts exactly. What Bruno said is fine as long as the current base group is removed first. Calling the new metapackage "base" sounds logical to me but anything else like "minimal-system" is fine too. Cheers. -- Gaetan
On Wed, 13 Feb 2019 08:55:27 +1000
Allan McRae via arch-dev-public
On 13/2/19 8:17 am, Levente Polyak via arch-dev-public wrote:
On 2/12/19 7:16 PM, Gaetan Bisson via arch-dev-public wrote:
[2019-02-12 16:40:08 +0100] Bruno Pagani via arch-dev-public:
Just in case it wasn’t clear, my answer would have been mostly the same as Eli’s.
So, Gaetan, Allan and Bartłomiej (or anyone else for that matter), do you have further comments/questions regarding this, does the existence of the base group alongside the arch/minimal-system now makes sense or would you still prefer to go without it?
Allan and I have both stated that we don't want to introduce a new group since we believe it would be highly redundant with base.
Nothing new has been said since our last messages except Eli's post which argues that the base group is largely inadequate in its current state. This further supports our proposal that base should be improved instead of introducing a new group.
So I really don't see what arguments could have changed our minds... It's also strange to me how you can concur with Eli's post without agreeing with our conclusions.
To go forward I suggest you propose a clear definition of the perfect "minimal system" group you'd want to have, along with a proposed list of packages. When consensus is reached, we adopt this list of packages for base and put this definition on the wiki.
Cheers.
To make it as short as possible, the idea is not just to strip down the base group further but primarily to not use a group in the first place. It should be replaced with something that is consistent within itself over the whole lifetime of the system. Groups are the wrong tool for such a set: you explicitly install all those packages so they won't automatically be mark as not-required anymore once removed from that group, as well as new additions are not consistent during the lifetime of the system.
We are clear about that. Call it a group or metapackage or whatever, the objection is having the current base and the new "group" at the same time.
A
Late to the party...
Assuming we implement this group or meta-package as something of policy, i.e. every repository package is assumed to depend on it. This would then make base similar to base-devel, except for depends() instead of makedepends().
With base-devel, we've always encouraged people to remove the makedepends already in that group. Would we do the same for "base", i.e. remove dependencies that, beforehand, were explicit?
As a concrete example, I have the udevil package which depends on udev. The udev package is provided by systemd. In the above case, systemd would in turn be "provided" by the base group (or meta-package). The explicit dependency might then be removed because some top-level package in "base" provides it.
Maybe I'm missing something. In any case, I agree that reducing the size of the base group is a good idea. I'm just not sure on the whole policy idea.
--
Alad Wenter
[2019-03-18 00:25:09 +0100] Alad Wenter via arch-dev-public:
Assuming we implement this group or meta-package as something of policy, i.e. every repository package is assumed to depend on it. This would then make base similar to base-devel, except for depends() instead of makedepends().
With base-devel, we've always encouraged people to remove the makedepends already in that group. Would we do the same for "base", i.e. remove dependencies that, beforehand, were explicit?
We've been doing this for as long as I can remember. Only 156 packages have glibc in their depends array. Cheers. -- Gaetan
[2019-03-17 13:35:55 -1000] Gaetan Bisson:
Only 156 packages have glibc in their depends array.
My bad. It's 624 packages for a total of 10.000. Cheers. -- Gaetan
On 18/03/2019 00.35, Gaetan Bisson via arch-dev-public wrote:
[2019-03-18 00:25:09 +0100] Alad Wenter via arch-dev-public:
Assuming we implement this group or meta-package as something of policy, i.e. every repository package is assumed to depend on it. This would then make base similar to base-devel, except for depends() instead of makedepends().
With base-devel, we've always encouraged people to remove the makedepends already in that group. Would we do the same for "base", i.e. remove dependencies that, beforehand, were explicit?
We've been doing this for as long as I can remember.
Only 156 packages have glibc in their depends array.
Cheers.
We is very generic term. I'm not doing it. If your package links to libc.so, put it into deps. Bartłomiej
participants (11)
-
Alad Wenter
-
Allan McRae
-
Bartłomiej Piotrowski
-
Bruno Pagani
-
Doug Newgard
-
Eli Schwartz
-
Gaetan Bisson
-
Giancarlo Razzolini
-
Jiachen YANG
-
Levente Polyak
-
Morten Linderud