[arch-dev-public] Follow-up on the “Proposal: minimal base system”

[Alad Wenter]

On Mon, 18 Mar 2019 08:49:16 +0100
Levente Polyak via arch-dev-public <arch-dev-public at archlinux.org> wrote:

> On March 18, 2019 8:39:45 AM GMT+01:00, "Bartłomiej Piotrowski via arch-dev-public" <arch-dev-public at 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 at 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 at archlinux.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20190318/01f12270/attachment.sig>