Breaking init swtich: was Re: sysvinit_3.14-2_source.changes ACCEPTED into experimental

[lorenzo]

Hi,

On Sun, 23 Feb 2025 23:22:50 +0100 (CET)
Thorsten Glaser <tg at evolvis.org> wrote:

> On Sun, 23 Feb 2025, Mark Hindley wrote:
> 
> >I don't think apt or dpkg recognise a 'group' of Protected: yes
> >packages with common Provides. But it might be a solution to propose.
> 
> I don’t think this meshes well with the current Provides, which has a
> long history as XB-Important.
> 
> >As Sean Whitton pointed
> >out, Protected: yes is poorly documented and its intended usage
> >unclear[1]
> 
> Huh? It does what it says it does, and it does that well.
> 
> --allow-remove-essential

note that for both apt and dpkg essential != protected

> 
> >I have just tried switching from sysvinit-core/experimental to
> >runit-init and the only way that succeeds for me is to use
> >
> >  DPKG_FORCE=remove-protected dpkg --remove sysvinit-core
> 
> Hmm. I don’t have a sid install at hand, but, supposedly,
> $ sudo apt-get --allow-remove-essential install systemd- sysvinit-core
> at least should work. Breaking out to dpkg is not something I’d
> consider acceptable.

as far as I know there is no flag to remove a protected package in apt,
for example (you can just test in a debootstrap sid chroot)

# dpkg -l | grep sysvinit
ii  orphan-sysvinit-scripts      0.17                        all          Orphaned System-V-like init scripts
ii  sysvinit-core                3.14-2                      amd64        System-V-like init
ii  sysvinit-utils               3.14-2                      amd64        System-V-like utilities

apt-get --allow-remove-essential install runit-init
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 runit-init : Conflicts: sysvinit-core but 3.14-2 is to be installed
 sysvinit-core : Conflicts: runit-init but 2.1.2-61 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.


now you need
dpkg --force-remove-protected sysvinit-core
then
apt-get install runit-init

in case of systemd-sysv I think it will be more complex because
there could be a stack of dependency on top of it, so something like

dpkg --force-remove-protected --force-depends -r systemd-sysv

and then it is to see if you can install an alternative init with apt
while there are unsatisfied dependency, worst case you need to play
again with 'dpkg --force-depends' and then 'apt -f install'

just a guess, we don't know for sure until a version of systemd with
the protected flag reaches the archive..

Lorenzo