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
-- Alad Wenter <alad@archlinux.org>