Project

General

Profile

Packaging request #2506

arch introduced a base metapackage to replace the meta group

oaken-source - about 1 month ago - . Updated 20 days ago.

Status:
open
Priority:
broken
Assignee:
-
% Done:

0%


Description

this change is announced here:
https://www.archlinux.org/news/base-group-replaced-by-mandatory-base-package-manual-intervention-required/

This means a couple of things:

  1. we need to forward the news announcement to our users, since the base metapackage was automatically pulled to our repos, and the same mitigation steps apply to our users as well.
  2. we need to update the installation guide since I believe the pacstrap calls need to be updated
    1. we need to review / update the installation media, in particular the more automated installers
  3. we need to review packages in the base group we repackage and determine whether their group entries can go away
  4. we need to review whether our helper scripts, such as the imagebuilder and vm bootstrap are impacted by this change
  5. we need to accomodate our openrc things towards using a metapackage as well
  6. we can probably drop base-meta from [pcr]
  7. we need to update our own infrastructure (winston / beefcake / ...) to accomodate that change, probably at least installing the base metapackage explicitly
  8. we need to look as base-devel and see what needs to be done there

let's go!

UPDATE:

package in base group, not in new base package:

> cryptsetup
> device-mapper
> dhcpcd
> e2fsprogs
> inetutils
> jfsutils
> logrotate
> lvm2
> man-db
> mdadm
> nano
> netctl
> pacman-mirrorlist
> perl
> reiserfsprogs
> s-nail
> sysfsutils
> texinfo
> usbutils
> vi
> xfsprogs
> your-system-sanity

packages in new base package, not in base group:

< coreutils
< file
< filesystem
< grep
< gzip
< licenses
< sed
< tar
< xz


Subtasks

Documentation - Housekeeping #2026: OpenRC documentation needs clarification and expansionopen

Actions
Housekeeping #2540: [pacman] update repos in pacman.conf and wikiin progressbill-auger

Actions
Housekeeping #2549: move non-systemd packages to [nonsystemd]in progress

Actions

History

#1

Updated by oaken-source about 1 month ago

  • Description updated (diff)
#2

Updated by Megver83 29 days ago

oaken-source wrote:

this change is announced here:
https://www.archlinux.org/news/base-group-replaced-by-mandatory-base-package-manual-intervention-required/

This means a couple of things:

  1. we need to forward the news announcement to our users, since the base metapackage was automatically pulled to our repos, and the same mitigation steps apply to our users as well.

I already did it
https://www.parabola.nu/news/base-group-replaced-by-mandatory-base-package-manual-intervention-required/

  1. we need to update the installation guide since I believe the pacstrap calls need to be updated

TODO

  1. we need to review / update the installation media, in particular the more automated installers

OK, I'll update those things from parabolaiso

  1. we need to review packages in the base group we repackage and determine whether their group entries can go away

I'm doing these with my pkgs (linux-libre and some [nonsystemd] pkgs)

  1. we need to review whether our helper scripts, such as the imagebuilder and vm bootstrap are impacted by this change

no idea about this

  1. we need to accomodate our openrc things towards using a metapackage as well
  2. we can probably drop base-meta from [pcr]

I created base-meta for non-systemd installations, but as now the base metapkg has systemd, I'll create a base metapkg replacement in [nonsystemd] that depends on an init provider (e.g. openrc-init or runit-replaceinit) and remove base-meta

  1. we need to update our own infrastructure (winston / beefcake / ...) to accomodate that change, probably at least installing the base metapackage explicitly

+1

  1. we need to look as base-devel and see what needs to be done there

good point, didn't think about it. Looks like it kept untouched

let's go!

Thanks for the well elaborated report!

#3

Updated by ovruni 24 days ago

I have added the base package to libre-testing repo: https://git.parabola.nu/abslibre.git/commit/?id=cf7d7163f0c89e0be326c91ed1ebe62cc2c932f5

The package contains as dependencies the packages of the libre repo that were in the base group.

#4

Updated by bill-auger 23 days ago

i think that part of the main idea of the new arch 'base' package is that it is considered to be mandatory, where the 'base' group was not -

the rationale is that these are all essential components that other parts of the system should assume to be present; analogous to the assumption of makepkg on the 'base-devel' group

'your-freedom' and 'your-system-sanity' are not in that class as nothing else in the system expects them to be present; which raises the question of whether or not those should be in the new 'base' package - this is mainly the question of: "do we consider systems without 'your-freedom' to be a complete parabola system?"; and that is mainly relevant to whether or not such a system is supported

semantically speaking, the purpose of the 'base' package is to maintain 'your-system-sanity'
that would imply (semantically) that 'base' should be a dependency of 'your-system-sanity'

practically speaking, its not clear how much significance there is in looking at it that way; but it is probably worth some discussion

#5

Updated by bill-auger 23 days ago

also for the sake of semantics, this ticket is marked "Bug" with "Priority: broken" - is anything actually broken, or is this a 'discussion' or 'housekeeping' task?

i ask this because it looks like another important issue that is being discussed only on IRC and redmine, that may never find its way onto the mailing list - doing so is essentially keeping users and inactive devs out of the know, and not asking for their opinions; which is actually quite against the "social contract" - very few people are subscribed to every redmine activity, and that is reasonable because bug trackers are generally only interesting to the devs and the OP of each ticket; but there are many people subscribed to the mailing list who would be interested in discussions and the decision making process

i would be in favor or restricting the use of redmine to tangible tasks that have been decided to done, and are clear how they should be done - surely something should be done regarding this issue; but whenever it is not clear exactly what do do; those discussions would be best on the mainling list

#6

Updated by oaken-source 23 days ago

This issue is probably too big to fit a single category. Under that perspective, it would make sense to split it, and have this one as the parent overall issue to track the individual ones. There's both housekeeping, as well as broken things here.

Concerning the your-freedom metapackage as dependency of the base metapackage, I'm very much a fan of the idea. base-the-metapackage was introduced in arch as a package that identifies a minimum set of installed packages make a system "officially supported" arch. Users are of course free to have base-the-metapackage not installed, and tamper with that list. If we apply the same logic to parabola, then your-freedom is definitely one of these packages that make parabola into parabola. And again, it's possible to uninstall your-freedom by not having base installed.

So my take on this would be yes, your-freedom is very much required to make a system a "complete" parabola system.

We can talk separately about whether having base-the-metapackage makes your-system-sanity obsolete.

#7

Updated by bill-auger 23 days ago

'your-system-sanity' would not be obsolete - it main purpose now
it to warn users about using third-party package managers -
another advanced use for it could be to conflict with them, and
perhaps package custom replacements that must be run as an
un-priviledged user

making 'base' a dependency of 'your-system-sanity' would just
add that extra explicity warning:

"removing package:'base' breaks 'your-system-sanity'"

#8

Updated by bill-auger 23 days ago

  • Description updated (diff)
#9

Updated by Megver83 23 days ago

bill-auger wrote:

'your-system-sanity' would not be obsolete - it main purpose now
it to warn users about using third-party package managers -
another advanced use for it could be to conflict with them, and
perhaps package custom replacements that must be run as an
un-priviledged user

making 'base' a dependency of 'your-system-sanity' would just
add that extra explicity warning:

"removing package:'base' breaks 'your-system-sanity'"

Or we can also put your-system-sanity as optdepends

#10

Updated by bill-auger 20 days ago

  • Status changed from confirmed to open
  • Tracker changed from Bug to Packaging request

i just noticed that the 'base-openrc' package group no longer installs a kernel - as i understand, the arch 'base' meta-package does not either; but the 'base-openrc' package group always did, and the wiki guide expects it to

i suppose i will just change the wiki guide for now - we should note that the current wiki guide instructs this command as the minimal base install:

# pacstrap /mnt base-openrc systemd-libs-dummy

and additionally, for an openrc desktop system:

# pacstrap /mnt openrc-desktop systemd-dummy polkit-elogind

so there a bit of a smell there - we can discuss whether the kernel can be in a 'base--openrc-extras' or whatever; but all of those above are currently mandatory in order to install the base system, with the exception of 'polkit-elogind'; so it would make most sense to add 'systemd-libs-dummy' to the 'base-openrc' group or new meta-package, and add 'systemd-dummy' to the 'openrc-desktop' group or new meta-package

though 'polkit-elogind' is indicated as optional; its not made clear in which cases one would not want it installed - it probably is the most common choice for the typical desktop system, so it is probably most reasonable to add that to the 'openrc-desktop' group or new meta-package as well

Also available in: Atom PDF