Project

General

Profile

Housekeeping #2549

Packaging request #2506: arch introduced a base metapackage to replace the meta group

move non-systemd packages to [nonsystemd]

bill-auger - 20 days ago - .

Status:
in progress
Priority:
bug
Assignee:
-
% Done:

0%


Description

the critical problem:

# pacstrap /mnt base
....
resolving dependencies...
:: There are 2 providers available for libsystemd:
:: Repository libre
   1) systemd-libs
:: Repository pcr
   2) systemd-libs-dummy

Enter a number (default=1): 
:: There are 2 providers available for libudev:
:: Repository libre
   1) systemd-libudev
:: Repository pcr
   2) eudev-libudev

Enter a number (default=1): 
:: There are 3 providers available for udev:
:: Repository libre
   1) notsystemd-udev  2) systemd-udev
:: Repository pcr
   3) eudev

Enter a number (default=1): 
looking for conflicting packages...
:: notsystemd-common and systemd-common are in conflict

there is an analogous but more subtle problem with `pacstrap base-openrc`, where the install succeeds; but most of systemd gets installed along with openrc, instead of the nonsystemd providers - that happens regardless of whether the [nonsystemd] repo is enabled or disabled; because 'systemd-libs' and 'systemd-libudev' in [libre] take precedence over the corresponding nonsystemd providers: 'systemd-libs-dummy' and 'eudev-libudev' in [pcr]

one can specify: `pacstrap base-openrc systemd-libs-dummy`; but then still 'systemd', 'systemd-common', and 'systemd-libsystemd', get installed unless the [nonsyetmd] repo is enabled - it is most likely that no one wants either of those situations, and they are likely to lead to problems; so it would make most sense if all of the packages in the 'base-openrc', 'openrc-desktop' groups/meta-packages would be invisible unless the [nonsyetmd] repo is enabled - in that case, `pacstrap base-openrc` would simply fail; and for the right reason , that the system-sans-systemd is not satisfyable or would be insane in that state - `pacstrap base` would still be troublesome while the [nonsyetmd] repo is enabled; but megver suggested renaming 'base-openrc' to 'base' after moving everything related to alternative initsystems into [nonsystemd] to make that situation sane also


in order to make the pacstrap process free of conflicts, this ticket is building upon the following IRC discussion:

<bill-auger> megver83: would it cause any problems to move all nonsystemd, notsystemd, systemd-dummy, elogind, eudev, and such all into the [nonststemd] repo? - i would very much like to do that this week
<bill-auger> right now it is not possible to pacstrap 'base' or 'base-openrc' as people expect should work - it is because those non-system packages are in [libre], and pkgnames starting with 'non*' which provide some systemd replacement take precedence over the systemd provider, with pkgnames starting with 'systemd*'
<bill-auger> to pactrap base now, one must specify `pacstrap /mnt base systemd-udev linux-libre`
<bill-auger> to pactrap base-openrc now, one must specify `pacstrap /mnt base-openrc systemd-libs-dummy linux-libre`
<bill-auger> so, at the very least the wiki guide needs to change - but i think that entire caveat and confusion would go away if everything related to alternative initsystems were moved into [nonsystemd]
<bill-auger> for the sake of semantics, it would make more sense to people that way too - is there any reason someone running systemd would want to install elogind, systemd-dummy, systemd-libs-dummy, eudev, notsystemd-udev ?
<megver83> bill-auger: I'll remove base-openrc - it will be replaced by nonsystemd/base
<megver83> bill-auger: makes sense to move those things to [nonsystemd], I'll check that later because it would also mean to move openrc, sysvinit and runit
<bill-auger> yes there are a bunch of them - i started a list but im sure i havent found them all yet
<bill-auger> i like the idea of nonsystemd/base - that makes the process transparent - simply having [nonsystemd] enabled and everything "just works" as expected
<megver83> I think I'll put the openrc init scripts immediately in the corresponding [nonsystemd] package so we don't have too many -openrc packages
<bill-auger> good pointi - deally we wuold not have any -openrc packages - they could have the same name as the related systemd package if kept in [nonsystemd]
<bill-auger> it would be nice if it were as simple as enabling or disabling [nonsystemd] then running pacman -Syyuu, in order to migrate from systemd to openec or the other direction at any time
<bill-auger> and finally close the openrc dcumentation ticket, once it makes sense to us and is fairly simple to explain to anyonw new
<megver83> the thing is that there are *many
packages that should go to [nonsystemd] and I cannot maintain all of them by myself
<bill-auger> you dont need to maintain them all - but you know better than anyone which ones they are - just move them
<megver83> so I prioritize packages that need to go there yes or yes
<megver83> I'm not referring to the packages from [pcr]
<megver83> I mean all the packages from Arch that I'm rebuilding in [nonsystemd]
<megver83> which I basically take from Artix, not difficult but takes time
<bill-auger> some of the non-systemd packages are in [pcr]
<megver83> bill-auger: I know, they are not the problem in fact
<megver83> but the first step is to get most of the thing working in [nonsystemd]
<bill-auger> yea agreed - just focus on making the system as free of conflicts as possible
<megver83> exactly, maybe planning a roadmap would be a good idea


Subtasks

Bug #2556: Conflict when updating openrc installconfirmedMegver83

Actions
Bug #2559: conflict installing openrc-desktopconfirmedMegver83

Actions
Bug #2574: "30-openrc-upgrade.hook line 2: invalid value Path" when trying to install or remove packageunconfirmedMegver83

Actions
Bug #2575: [avahi-openrc] Dependency errors when trying to upgrade with pacmanunconfirmedMegver83

Actions
Bug #2576: conflict upgrading openrc-desktopconfirmedMegver83

Actions

Also available in: Atom PDF