Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1020290: init-system-helpers depends on usrmerge | usr-is-merged
598 views
Skip to first unread message
Craig Sanders
Sep 19, 2022, 7:50:03 AM9/19/22
to
Package: init-system-helpers
Version: 1.65.2
dist-upgrade was broken on four systems tonight due to:
Depends: usrmerge | usr-is-merged
This effectively makes these packages Essential by stealth. Debian's usrmerge
FAQ says:
* Is it mandatory to install this package?
No.
All four systems (3 running systemd, one running sysvinit - because systemd
is incapable of booting this machine) gave the following error message and
aborted the upgrade:
Selecting previously unselected package usr-is-merged.
Preparing to unpack .../01-usr-is-merged_30+nmu1_all.deb ...
******************************************************************************
*
* The usr-is-merged package cannot be installed because this system does
* not have a merged /usr.
*
* Please install the usrmerge package to convert this system to merged-/usr.
*
* For more information please read https://wiki.debian.org/UsrMerge.
*
******************************************************************************
dpkg: error processing archive /tmp/user/0/apt-dpkg-install-zRN5ON/01-usr-is-merged_30+nmu1_all.deb (--unpack):
new usr-is-merged package pre-installation script subprocess returned error exit status 1
.
.
.
Errors were encountered while processing:
/tmp/user/0/apt-dpkg-install-zRN5ON/01-usr-is-merged_30+nmu1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
This could only be fixed by reverting back to 1.64 and purging usr-is-merged,
followed by 'apt-mark hold init-system-helpers' of course.
This is an essential package. Why is it forcing this usr merge idiocy on me,
even on systems that don't run systemd? what actual benefit does it provide?
And WTF does forcing usrmerge have to do with init-system-helpers' purpose?
How does forcing usrmerge qualify as a helper tool for switching between "all"
init systems?
Description-en: helper tools for all init systems
This package contains helper tools that are necessary for switching
between the various init systems that Debian contains (e. g. sysvinit
or systemd). An example is deb-systemd-helper, a script that enables
systemd unit files without depending on a running systemd.
.
It also includes the "service", "invoke-rc.d", and "update-rc.d"
scripts which provide an abstraction for enabling, disabling,
starting, and stopping services for all supported Debian init systems
as specified by the policy.
.
While this package is maintained by pkg-systemd-maintainers, it is
NOT specific to systemd at all. Maintainers of other init systems are
welcome to include their helpers in this package.
craig
ps: I'm annoyed enough that this tried to install usr-is-merged and failed.
I would have been furious if it had successfully installed usrmerge and
irreversibly fucked with my filesystems without warning and especially without
my CONSENT.
Version: 1.65.2
dist-upgrade was broken on four systems tonight due to:
Depends: usrmerge | usr-is-merged
This effectively makes these packages Essential by stealth. Debian's usrmerge
FAQ says:
* Is it mandatory to install this package?
No.
All four systems (3 running systemd, one running sysvinit - because systemd
is incapable of booting this machine) gave the following error message and
aborted the upgrade:
Selecting previously unselected package usr-is-merged.
Preparing to unpack .../01-usr-is-merged_30+nmu1_all.deb ...
******************************************************************************
*
* The usr-is-merged package cannot be installed because this system does
* not have a merged /usr.
*
* Please install the usrmerge package to convert this system to merged-/usr.
*
* For more information please read https://wiki.debian.org/UsrMerge.
*
******************************************************************************
dpkg: error processing archive /tmp/user/0/apt-dpkg-install-zRN5ON/01-usr-is-merged_30+nmu1_all.deb (--unpack):
new usr-is-merged package pre-installation script subprocess returned error exit status 1
.
.
.
Errors were encountered while processing:
/tmp/user/0/apt-dpkg-install-zRN5ON/01-usr-is-merged_30+nmu1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
This could only be fixed by reverting back to 1.64 and purging usr-is-merged,
followed by 'apt-mark hold init-system-helpers' of course.
This is an essential package. Why is it forcing this usr merge idiocy on me,
even on systems that don't run systemd? what actual benefit does it provide?
And WTF does forcing usrmerge have to do with init-system-helpers' purpose?
How does forcing usrmerge qualify as a helper tool for switching between "all"
init systems?
Description-en: helper tools for all init systems
This package contains helper tools that are necessary for switching
between the various init systems that Debian contains (e. g. sysvinit
or systemd). An example is deb-systemd-helper, a script that enables
systemd unit files without depending on a running systemd.
.
It also includes the "service", "invoke-rc.d", and "update-rc.d"
scripts which provide an abstraction for enabling, disabling,
starting, and stopping services for all supported Debian init systems
as specified by the policy.
.
While this package is maintained by pkg-systemd-maintainers, it is
NOT specific to systemd at all. Maintainers of other init systems are
welcome to include their helpers in this package.
craig
ps: I'm annoyed enough that this tried to install usr-is-merged and failed.
I would have been furious if it had successfully installed usrmerge and
irreversibly fucked with my filesystems without warning and especially without
my CONSENT.
Craig Sanders
Sep 19, 2022, 9:10:04 AM9/19/22
to
reopen 1020290
stop
> > This effectively makes these packages Essential by stealth. Debian's
> usrmerge
> > FAQ says:
> >
> > * Is it mandatory to install this package?
> > No.
>
> That is correct - new installations are already merged-usr so there's no
> need for that package, hence the creation of usr-is-merged, which attests
> that the system is merged but doesn't otherwise do anything.
That's a particularly specious and disingenuous statement.
What you're actually saying is "It's mandatory if you haven't conformed yet".
In other words: it's mandatory but you don't want to admit it.
> It is strange that the upgrade didn't pick usrmerge though, did you block it
> locally somehow?
Nope. I had no idea this stealth-mandatory change was being forced.
I will when I have a few minutes to figure out how, though. Maybe a dummy
package with an appropriate Conflicts line.
Doesn't matter whether I do or not, it's broken right now anyway.
apt wants to install usr-is-merged in preference to usrmerge. I just tried
dist-upgrading a fairly minimal sid VM (which was last upgraded about two
weeks ago and still has separate /bin, /lib, /sbin, etc - and is exactly the
kind of bog-standard debian install that you'd expect something like this to
actually work 100% smoothly on) and got:
The following NEW packages will be installed:
usr-is-merged (30+nmu1)
It's not even possible to manually install usrmerge:
# apt-get -d -u install usrmerge
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package usrmerge is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'usrmerge' has no installation candidate
But usrmerge does exist, it is available, there is an installation candidate:
# apt-cache show usrmerge
Package: usrmerge
Version: 30+nmu1
Installed-Size: 39
Maintainer: Marco d'Itri <m...@linux.it>
Architecture: all
Provides: usr-is-merged
Depends: perl:any, libfile-find-rule-perl
.....
Perhaps you haven't planned this insane, unwanted transition as well as you
thought you had? Maybe you should step back and think again before you
arbitrarily break other people's systems for pointless cosmetic reasons?
> The transition is mandatory and from Bookworm only merged-usr systems will
> be supported.
Why? I mean, apart from worshipping the sun shining out of Saint Poettering's
arse, why? What actual, practical, non-theological benefit is there?
It was a mistake for debian to stop supporting a separate /usr, and this only
cements that mistake by making it impossible to ever revert and impossible
even for local system admins to DIY.
stop
> > This effectively makes these packages Essential by stealth. Debian's
> usrmerge
> > FAQ says:
> >
> > * Is it mandatory to install this package?
> > No.
>
> need for that package, hence the creation of usr-is-merged, which attests
> that the system is merged but doesn't otherwise do anything.
That's a particularly specious and disingenuous statement.
What you're actually saying is "It's mandatory if you haven't conformed yet".
In other words: it's mandatory but you don't want to admit it.
> It is strange that the upgrade didn't pick usrmerge though, did you block it
> locally somehow?
Nope. I had no idea this stealth-mandatory change was being forced.
I will when I have a few minutes to figure out how, though. Maybe a dummy
package with an appropriate Conflicts line.
Doesn't matter whether I do or not, it's broken right now anyway.
apt wants to install usr-is-merged in preference to usrmerge. I just tried
dist-upgrading a fairly minimal sid VM (which was last upgraded about two
weeks ago and still has separate /bin, /lib, /sbin, etc - and is exactly the
kind of bog-standard debian install that you'd expect something like this to
actually work 100% smoothly on) and got:
The following NEW packages will be installed:
usr-is-merged (30+nmu1)
It's not even possible to manually install usrmerge:
# apt-get -d -u install usrmerge
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package usrmerge is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'usrmerge' has no installation candidate
But usrmerge does exist, it is available, there is an installation candidate:
# apt-cache show usrmerge
Package: usrmerge
Version: 30+nmu1
Installed-Size: 39
Maintainer: Marco d'Itri <m...@linux.it>
Architecture: all
Provides: usr-is-merged
Depends: perl:any, libfile-find-rule-perl
.....
Perhaps you haven't planned this insane, unwanted transition as well as you
thought you had? Maybe you should step back and think again before you
arbitrarily break other people's systems for pointless cosmetic reasons?
> The transition is mandatory and from Bookworm only merged-usr systems will
> be supported.
Why? I mean, apart from worshipping the sun shining out of Saint Poettering's
arse, why? What actual, practical, non-theological benefit is there?
It was a mistake for debian to stop supporting a separate /usr, and this only
cements that mistake by making it impossible to ever revert and impossible
even for local system admins to DIY.
Ansgar
Sep 19, 2022, 9:30:04 AM9/19/22
to
Hi Craig,
I think your behavior on Debian lists is not acceptable. This isn't the
first time either.
You are free to leave the project (and Debian lists) if you want to
behave like that.
Ansgar
On Mon, 2022-09-19 at 22:53 +1000, Craig Sanders wrote:
> That's a particularly specious and disingenuous statement.
[...]
I think your behavior on Debian lists is not acceptable. This isn't the
first time either.
You are free to leave the project (and Debian lists) if you want to
behave like that.
Ansgar
On Mon, 2022-09-19 at 22:53 +1000, Craig Sanders wrote:
> That's a particularly specious and disingenuous statement.
> Perhaps you haven't planned this insane, unwanted transition as well as you
> thought you had? Maybe you should step back and think again before you
> arbitrarily break other people's systems for pointless cosmetic reasons?
[...]
> thought you had? Maybe you should step back and think again before you
> arbitrarily break other people's systems for pointless cosmetic reasons?
Craig Sanders
Sep 20, 2022, 7:40:04 AM9/20/22
to
reopen 1020290
severity 1020290 critical
stop
In case you didn't notice, there's a real bug here.
Your broken init-system-helpers package breaks apt upgrade and dist-upgrade,
and since this is an Essential package, that makes it a critical bug.
It doesn't matter at all whether you like my tone or not (I didn't like your
condescending and dismissive tone in your reply to my bug report, but I doubt
you give a damn about that either). There's a critical bug in your package
and you need to fix it.
craig
severity 1020290 critical
stop
In case you didn't notice, there's a real bug here.
Your broken init-system-helpers package breaks apt upgrade and dist-upgrade,
and since this is an Essential package, that makes it a critical bug.
It doesn't matter at all whether you like my tone or not (I didn't like your
condescending and dismissive tone in your reply to my bug report, but I doubt
you give a damn about that either). There's a critical bug in your package
and you need to fix it.
craig
Helmut Grohne
Sep 21, 2022, 2:40:03 AM9/21/22
to
Hi Craig,
Speaking with a CTTE hat.
On Wed, Sep 21, 2022 at 10:41:18AM +1000, Craig Sanders wrote:
> Stop closing this bug without fixing it.
The change you are objecting to was planned and presented to various
teams in Debian including the technical committee and the release team.
The change is implementing a technical committee decision and has been
agreed to by the technical committee and the release team. You should be
able to find the rationale in the relevant technical committee bug
reports. If you want to change this, please file your objection with the
technical committee or start a GR instead of reopening this bug over and
over again.
> It is breaking upgrades and dist-upgrades etc.
As others have pointed out, this is breaking on your side, because
usrmerge is somehow prevented from being installable. Please figure out
why that happens. I suppose the most likely cause would be use of
dpkg-fsys-usrunmess. Refer to the new faq entry at
https://wiki.debian.org/UsrMerge on how to revert that.
Helmut
Speaking with a CTTE hat.
On Wed, Sep 21, 2022 at 10:41:18AM +1000, Craig Sanders wrote:
> Stop closing this bug without fixing it.
The change you are objecting to was planned and presented to various
teams in Debian including the technical committee and the release team.
The change is implementing a technical committee decision and has been
agreed to by the technical committee and the release team. You should be
able to find the rationale in the relevant technical committee bug
reports. If you want to change this, please file your objection with the
technical committee or start a GR instead of reopening this bug over and
over again.
> It is breaking upgrades and dist-upgrades etc.
As others have pointed out, this is breaking on your side, because
usrmerge is somehow prevented from being installable. Please figure out
why that happens. I suppose the most likely cause would be use of
dpkg-fsys-usrunmess. Refer to the new faq entry at
https://wiki.debian.org/UsrMerge on how to revert that.
Helmut
Jakub Wilk
Sep 21, 2022, 1:00:03 PM9/21/22
to
* Craig Sanders <c...@taz.net.au>, 2022-09-19 22:53:
Can you run this command on the affected system
apt-cache policy usrmerge usr-is-merged
and paste the output? This could shed some light on what's going on.
--
Jakub Wilk
># apt-get -d -u install usrmerge
>Reading package lists... Done
>Building dependency tree... Done
>Reading state information... Done
>Package usrmerge is not available, but is referred to by another package.
>This may mean that the package is missing, has been obsoleted, or
>is only available from another source
>
>E: Package 'usrmerge' has no installation candidate
This is very odd and it definitely doesn't happen here.
>Reading package lists... Done
>Building dependency tree... Done
>Reading state information... Done
>Package usrmerge is not available, but is referred to by another package.
>This may mean that the package is missing, has been obsoleted, or
>is only available from another source
>
>E: Package 'usrmerge' has no installation candidate
Can you run this command on the affected system
apt-cache policy usrmerge usr-is-merged
and paste the output? This could shed some light on what's going on.
--
Jakub Wilk
Craig Sanders
Sep 21, 2022, 7:10:03 PM9/21/22
to
On Wed, Sep 21, 2022 at 03:27:04PM +0200, Michael Biebl wrote:
> Unfortunately it is not possible to address the issue you are seeing without
> further information or having a way to reproduce the issue.
Finally, a response that isn't just 1. smug dismissal by quibbling about what
"mandatory" means, 2. posturing by a self-important busybody or 3. just misses
the point.
But it's too late, I've lost interest and I have no more energy to deal with
the hostility and dog-piling.
I'll just leave init-systems-helpers held at 1.64 forever. or until it causes
enough problems that I need to do something about it. That works for me, and
I no longer care if it's still broken for others.
> Maybe you can provide a minimal reproducer (based on a minimal chroot).
Making a stable VM and then upgrading it to sid should show it.
craig
> Unfortunately it is not possible to address the issue you are seeing without
> further information or having a way to reproduce the issue.
Finally, a response that isn't just 1. smug dismissal by quibbling about what
"mandatory" means, 2. posturing by a self-important busybody or 3. just misses
the point.
But it's too late, I've lost interest and I have no more energy to deal with
the hostility and dog-piling.
I'll just leave init-systems-helpers held at 1.64 forever. or until it causes
enough problems that I need to do something about it. That works for me, and
I no longer care if it's still broken for others.
> Maybe you can provide a minimal reproducer (based on a minimal chroot).
Making a stable VM and then upgrading it to sid should show it.
craig
Stuart Prescott
Sep 23, 2022, 4:40:04 AM9/23/22
to
On Thu, 22 Sep 2022 08:59:17 +1000 Craig Sanders <c...@taz.net.au> wrote:
> > Maybe you can provide a minimal reproducer (based on a minimal chroot).
>
> Making a stable VM and then upgrading it to sid should show it.
Nope. If it were that easy to reproduce and the package were that buggy, it
> > Maybe you can provide a minimal reproducer (based on a minimal chroot).
>
> Making a stable VM and then upgrading it to sid should show it.
would never have been uploaded. (Please offer a tiny bit of respect to your
fellow developers!)
You might be unaware that stable→sid upgrades are tested automatically, and
that the problem can't be reproduced there either.
https://piuparts.debian.org/stable2sid/source/i/init-system-helpers.html
https://piuparts.debian.org/stable2sid/pass/init-system-helpers_1.65.2.log
Understanding what provoked apt to pick the wrong package on your particular
system is needed here. Quite obviously no-one else can reproduce it (or, once
again, it wouldn't have been uploaded). Also obviously, if there are no
details, it won't be fixed except perhaps by accident.
The output of « apt list '~o' » and « apt-cache policy » might have useful
clues still.
> But it's too late, I've lost interest and I have no more energy to deal with
> the hostility and dog-piling.
high moral ground about the tone of the discussion.
--
Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Craig Sanders
Sep 23, 2022, 5:40:03 AM9/23/22
to
On Fri, Sep 23, 2022 at 06:27:51PM +1000, Stuart Prescott wrote:
> Nope. If it were that easy to reproduce and the package were that buggy, it
> would never have been uploaded. (Please offer a tiny bit of respect to your
> fellow developers!)
The bug is closed, you lot have dog-piled enough, and respect is earned, not
> Nope. If it were that easy to reproduce and the package were that buggy, it
> would never have been uploaded. (Please offer a tiny bit of respect to your
> fellow developers!)
an entitlement. I respond to dismissive contempt with more of the same.
I certainly have no respect or tolerance for posturing busybody wankers
pretending they have the high moral ground.
More importantly, I really do not give a fuck any more. I have my own
workaround for a shitty broken package that does a shitty job of implementing
a stupid and pointless idea.
Go away and stop bothering me.
craig
Christoph Berg
Sep 23, 2022, 7:30:03 AM9/23/22
to
Re: Craig Sanders
I think that was well beyond what could be acceptable for a Debian
member to behave like. Have you considering finding other venues?
Christoph
> I certainly have no respect or tolerance for posturing busybody wankers
> pretending they have the high moral ground.
Hi Craig,
> pretending they have the high moral ground.
I think that was well beyond what could be acceptable for a Debian
member to behave like. Have you considering finding other venues?
Christoph
Craig Sanders
Sep 23, 2022, 10:50:03 AM9/23/22
to
On Fri, Sep 23, 2022 at 01:17:52PM +0200, Christoph Berg wrote:
> I think that was well beyond what could be acceptable for a Debian member to
> behave like. Have you considering finding other venues?
Have you considered minding your own fucking business? You've all been
> I think that was well beyond what could be acceptable for a Debian member to
> behave like. Have you considering finding other venues?
fucking dog-piling me since I first posted the fucking bug report, and I'm
fucking sick of it.
Obviously I've beens far too subtle for you fuckers to understand, so I'll
state it very plainly so that even a cretin can understand:
ALL OF YOU FUCK OFF AND STOP FUCKING HARASSING ME.
0 new messages