Hi there,
This is a follow-up on the last month discussion about a “minimal base system”.
# Reminder of the starting statement
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 corollary being that, since we don’t actually enforce `base` as a policy, some breakage might (and does) happen when people remove part of it from their system.
Following on that, the discussion was about implementing a metapackage with a stricter set of packages to be required as installed on any Arch system, and whether or not to keep the `base` group in addition. From this discussion and parallel ones that happened on IRC, I can summarize three important questions (that are, notice, actually independent of the exact content of base-whatever):
1. There is a disagreement on the `base` group purpose: should it just be a convenient helper to bootstrap an Arch system quickly and/or also be used as a set of assumed installed dependencies?
2. Are people actually wanting to be able to assume some installed dependencies at all, and if so, what are they argument(s) for not listing some, e.g. `glibc`? I haven’t seen many apart from “don’t want to list tons of dependency in my PKGBUILD” or “no sane system wouldn’t have it”, and we can discuss whether those are valid one or not, but since the discussion wasn’t happening on that point particularly, there may also be some others that have escaped me.
3. Although it could seems not deeply related at first, what about transitive dependencies (e.g. package A depending on B and C, but only listing B because this one already depends on C)? Here again, breakage happens because of this (when B stop depending on C, which A maintainer cannot be reasonably expected to track), and I’ve only heard “don’t want to list tons of dependency in my PKGBUILD”.
Before going further on any proposal in those directions, I’ve thought it surely requires more input, and not only from the ~10 people at most that already participated in those discussions (but still should, because points have changed a bit) since we are discussing distro-wide policy on dependencies here.
Regards, Bruno
[2019-03-17 19:07:23 +0100] Bruno Pagani via arch-dev-public:
This is a follow-up on the last month discussion about a “minimal base system”.
Creating a new thread removed from the discussion we had a month ago just makes it so much harder for all of us to remember what everyone's arguments and counter-arguments were. Please do not do this. For my part, I thought we had reached consensus with Allan's message:
https://lists.archlinux.org/pipermail/arch-dev-public/2019-February/029471.h...
Summary: You propose what you want your new group to be (metapackage, list of dependencies, etc.) and we adopt this as the new base.
If that is not satisfactory to you, please reply to that specific message and say why. That would have been far more constructive than your present message which rehashes some of the discussion we've already had and adds new questions I have no idea where you're going with.
From this discussion and parallel ones that happened on IRC,
Not everyone is awake all the time, which is why decisions are made on this very list, not on IRC. New arguments should have been posted to the previous thread.
Before going further on any proposal in those directions, I’ve thought it surely requires more input, and not only from the ~10 people at most that already participated in those discussions
It's probably safe to guess that people who haven't participated so far just aren't interesting in participating. Besides, I think you'd have more feedback and clear answers to a concrete proposal.
Cheers.
Le 17/03/2019 à 23:13, Gaetan Bisson via arch-dev-public a écrit :
[2019-03-17 19:07:23 +0100] Bruno Pagani via arch-dev-public:
This is a follow-up on the last month discussion about a “minimal base system”.
Creating a new thread removed from the discussion we had a month ago just makes it so much harder for all of us to remember what everyone's arguments and counter-arguments were. Please do not do this.
Well, people on IRC advised me to do the exact opposite of what you said (a.k.a. starting a new thread with a TL;DR of the previous one), so…
For my part, I thought we had reached consensus with Allan's message:
https://lists.archlinux.org/pipermail/arch-dev-public/2019-February/029471.h...
Summary: You propose what you want your new group to be (metapackage, list of dependencies, etc.) and we adopt this as the new base.
If that is not satisfactory to you, please reply to that specific message and say why. That would have been far more constructive than your present message which rehashes some of the discussion we've already had and adds new questions I have no idea where you're going with.
I was satisfied with the consensus we reached, but when I asked on IRC how I should revive the thread so that we move on with that proposal to an actual implementation, I faced concerns about this proposal from several persons. The conclusion of our discussions was that we apparently didn’t even agree on the premises, so that the discussion should restart at a more fundamental level.
From this discussion and parallel ones that happened on IRC,
Not everyone is awake all the time, which is why decisions are made on this very list, not on IRC. New arguments should have been posted to the previous thread.
And I hope they will, since I was asked to resend a new e-mail with the base line-up of the matter at hand.
Before going further on any proposal in those directions, I’ve thought it surely requires more input, and not only from the ~10 people at most that already participated in those discussions
It's probably safe to guess that people who haven't participated so far just aren't interesting in participating. Besides, I think you'd have more feedback and clear answers to a concrete proposal.
I actually thought the same, but that was before I got more feedback on IRC (of either people that missed the thread, or had their concerns unadressed because not understood by others in the way they were meant to be expressed for instance). I’ll let this thread in this way for some days on move-on with a concrete proposal depending on the output.
People seem concerned about implicit dependencies at all, and also wonder about group vs metapackage. All of this is related, for instance we don’t need a metapackage if we go the no implicit deps way, and I don’t really care either about the content of the base-whatever in this case.
In my case, I don’t have strong opinions about implicit deps from a reasonably small metapackage (i.e. previous proposal) or no implicit deps at all (someone else proposal), but I’m strongly against transitive deps in any case. So I’m not decided yet on which proposal to push forward on.
Regards, Bruno
[2019-03-17 23:29:12 +0100] Bruno Pagani via arch-dev-public:
I was satisfied with the consensus we reached, but when I asked on IRC how I should revive the thread so that we move on with that proposal to an actual implementation, I faced concerns about this proposal from several persons.
I see.
Most devs, myself included, have no idea who told you what on IRC and I really wish you'd give zero credit to the opinions of those who cannot be bothered to write their thoughts clearly and send a public message to this list so everyone has a chance to read and comment on them.
We're reached consensus in the open discussion we've had here last month, where every dev and TU was free to contribute, without timezone problems, etc. That's all that matters.
The conclusion of our discussions was that we apparently didn’t even agree on the premises, so that the discussion should restart at a more fundamental level.
That doesn't sound like moving forward to me. Agreeing on conclusions should be enough. We don't need to see eye-to-eye on everything.
Cheers.
On March 17, 2019 11:13:31 PM GMT+01:00, Gaetan Bisson via arch-dev-public arch-dev-public@archlinux.org wrote:
[2019-03-17 19:07:23 +0100] Bruno Pagani via arch-dev-public:
This is a follow-up on the last month discussion about a “minimal
base
system”.
Creating a new thread removed from the discussion we had a month ago just makes it so much harder for all of us to remember what everyone's arguments and counter-arguments were. Please do not do this. For my part, I thought we had reached consensus with Allan's message:
https://lists.archlinux.org/pipermail/arch-dev-public/2019-February/029471.h...
Summary: You propose what you want your new group to be (metapackage, list of dependencies, etc.) and we adopt this as the new base.
If that is not satisfactory to you, please reply to that specific message and say why. That would have been far more constructive than your present message which rehashes some of the discussion we've already had and adds new questions I have no idea where you're going with.
I thought so too, also don't really see why we need a different set than the one already proposed but curious to hear. I just didn't went any further yet to give more time for people to potentially talk about something not yet mentioned. I don't quite see why we are facing something very time critical here so it's fine to wait a bit and give people enough room to feel comfortable with this whole change.
Cheers, Levente
On 17/03/2019 23.13, Gaetan Bisson via arch-dev-public wrote:
[2019-03-17 19:07:23 +0100] Bruno Pagani via arch-dev-public:
This is a follow-up on the last month discussion about a “minimal base system”.
Creating a new thread removed from the discussion we had a month ago just makes it so much harder for all of us to remember what everyone's arguments and counter-arguments were. Please do not do this. For my part, I thought we had reached consensus with Allan's message:
I asked Bruno to start another round as previous thread is way too long for people who missed the party to catch up.
https://lists.archlinux.org/pipermail/arch-dev-public/2019-February/029471.h...
Summary: You propose what you want your new group to be (metapackage, list of dependencies, etc.) and we adopt this as the new base.
If that is not satisfactory to you, please reply to that specific message and say why. That would have been far more constructive than your present message which rehashes some of the discussion we've already had and adds new questions I have no idea where you're going with.
The previous discussion doesn't answer (or even if it does, I don't care to re-read it at this point) if the idea behind the new metapackage is to be implicit dependency of all packages or just optional thing like base group always was.
Currently maintainers either put actual dependencies into depends=(), including glibc if something dynamically links to libc.so or assume that base is group expected to be present on every installation, which I wholeheartedly disagree with, because I can just instead use Slackware if I weren't caring about dependency system.
Bartłomiej
On March 18, 2019 8:39:45 AM GMT+01:00, "Bartłomiej Piotrowski via arch-dev-public" arch-dev-public@archlinux.org wrote:
The previous discussion doesn't answer (or even if it does, I don't care to re-read it at this point) if the idea behind the new metapackage is to be implicit dependency of all packages or just optional thing like base group always was.
Currently maintainers either put actual dependencies into depends=(), including glibc if something dynamically links to libc.so or assume that base is group expected to be present on every installation, which I wholeheartedly disagree with, because I can just instead use Slackware if I weren't caring about dependency system.
I don't quite see why we are pulling together two topics into one, implicit or no implicit dependencies are NOT depending on the metapackage in any mean. It's just a consistent and proper way to handle dependencies of that base. It is free to exist with or without explicit dependencies. I frankly am on the no imicit dependency front and my packages depend on glibc as well still I want to make that base a properly dependency handles meta package. As we are drifting up here to the transitive dependencies topic let it be separated from the original topic, base is about the foundation for a system but as metapackage to have actually meaningful dependency handling of that set. Implicit dependencies are something else.
Cheers Levente
On Mon, 18 Mar 2019 08:49:16 +0100 Levente Polyak via arch-dev-public arch-dev-public@archlinux.org wrote:
On March 18, 2019 8:39:45 AM GMT+01:00, "Bartłomiej Piotrowski via arch-dev-public" arch-dev-public@archlinux.org wrote:
The previous discussion doesn't answer (or even if it does, I don't care to re-read it at this point) if the idea behind the new metapackage is to be implicit dependency of all packages or just optional thing like base group always was.
Currently maintainers either put actual dependencies into depends=(), including glibc if something dynamically links to libc.so or assume that base is group expected to be present on every installation, which I wholeheartedly disagree with, because I can just instead use Slackware if I weren't caring about dependency system.
I don't quite see why we are pulling together two topics into one, implicit or no implicit dependencies are NOT depending on the metapackage in any mean. It's just a consistent and proper way to handle dependencies of that base. It is free to exist with or without explicit dependencies. I frankly am on the no imicit dependency front and my packages depend on glibc as well still I want to make that base a properly dependency handles meta package. As we are drifting up here to the transitive dependencies topic let it be separated from the original topic, base is about the foundation for a system but as metapackage to have actually meaningful dependency handling of that set. Implicit dependencies are something else.
I've been looking at your original proposal again (and added the full text below for reference.) If you don't mind, let me restate my understanding of it.
As you mention, it does seem that the proposal leaves the choice of using explicit or implicit dependencies. In particular (emphasis mine):
"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."
If we then reduce the size of the base group, which I believe none of us object to, the benefit in using a meta-package would then be to easily propagate changes to "base" to all Arch systems, which a package group does not allow, correct? (I suppose a meta-package also allows easier changes to the definition of "base", without requiring PKGBUILD edits to specific packages.)
If I'm right and we're otherwise on the same page, we could perhaps proceed in the following way.
1. Remove packages not required for a minimal booting system from the base group. 2. Replace the now smaller base group with a base meta-package which serves the same purpose, but has the benefits described above. 3. Remove the base group from the remaining packages now in the metapackage. 4. If we still feel like it, talk about implicit vs. explicit and transitive dependencies, similar to the discussion in 2011.
- Text of original proposal:
On Mon, 21 Jan 2019 23:03:02 +0100 Levente Polyak via arch-dev-public arch-dev-public@archlinux.org 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
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
[2019-03-18 08:39:45 +0100] Bartłomiej Piotrowski via arch-dev-public:
I asked Bruno to start another round as previous thread is way too long for people who missed the party to catch up.
So some of us have taken the time to discuss this issue just a month ago but because it's too much to read for you we must start all over again?
Currently maintainers either put actual dependencies into depends=(), including glibc if something dynamically links to libc.so or assume that base is group expected to be present on every installation, which I wholeheartedly disagree with
I'm fine with both but, again, I note that we've been using the second option for as far back as I can remember, even before you became a TU. Some people were pushing for sodeps at some point but it did not go far. If it's not too much to read, have a look at this old thread that discussed your exact issue:
https://lists.archlinux.org/pipermail/aur-general/2011-January/013256.html
Anyhow.
We currently have a base group that you're not happy with. Levente and Bruno suggest to update its package list and/or maybe make it a meta- package. From your perspective that would be no better and no worse than the current situation, right? So I don't see why you are against this change but if you are please tell us what concretely you propose we do?
Cheers.
On 18/03/2019 09.18, Gaetan Bisson via arch-dev-public wrote:
[2019-03-18 08:39:45 +0100] Bartłomiej Piotrowski via arch-dev-public:
I asked Bruno to start another round as previous thread is way too long for people who missed the party to catch up.
So some of us have taken the time to discuss this issue just a month ago but because it's too much to read for you we must start all over again?
I am sorry for bringing forth an idea of recapping what we agree or not agree upon after hearing that the thread could be too long for bystanders.
We currently have a base group that you're not happy with. Levente and Bruno suggest to update its package list and/or maybe make it a meta- package. From your perspective that would be no better and no worse than the current situation, right? So I don't see why you are against this change but if you are please tell us what concretely you propose we do?
It will be later leveraged to vouch for implicit or transitive dependencies. If you consider it independent topic then fine, I'm happy to bring it up as "but that's unrelated" counterargument in the future.
Bartłomiej
arch-dev-public@lists.archlinux.org