[arch-dev-public] Proposal: minimal base system

Eli Schwartz eschwartz at archlinux.org
Mon Jan 21 22:26:47 UTC 2019


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20190121/fad512ae/attachment.asc>


More information about the arch-dev-public mailing list