Re: Bug#773256: pre-approval: unblock: dpkg/1.17.23
Hi!
On Sun, 2014-12-21 at 09:57:51 +0100, Niels Thykier wrote:
> It possibly still is since the version that introduced the trigger
> checks. I hope we can have it resolved shortly.
Yeah, I'm planning to upload tomorrow, sorry about the delay, was not
feeling quite well the past couple of days.
> >> It seems that only gxine and icecc are missing now. If so, please go
> >> ahead with the .23 with versioned breaks for them as well. Worst case,
> >> I will have them removed from testing - best case, they will be fixed.
> >> I will take the political fall-out of this and notify the maintainers
> >> of the affected packages. Let me know if I missed any packages.
> >
> > Unfortunately there's still auctex, gxine, icecc, mcollective, pypy
> > and wordpress. And I'm not sure if the fix for all of them might be
> > a strightforward switch to a -noawait directive.
>
> Indeed I missed those. For reference, pypy got fixed and gxine, icecc
> and mcollective will get auto-removed eventually. My previous remark
> for gxine plus icecc applies equally to mcollective (and pypy, in case
> migration is stalled) as well.
> This leaves auctex as the only remaining blocker auctex.
In the meantime mcollective also got fixed, which leaves auctex, gxine,
icecc and wordpress. The latter has a fixed package sitting in NEW
(but I'm not sure it will be accepted and allowed to migrate?).
I've added << versioned Breaks for the packages with fixed versions,
and <= for the ones with unfixed ones against the version in testing
(as for auctex it differs against unstable).
> >>> I've also not added the --force-configure-any default switch, because we
> >>> don't really know what happened with apt and dbus there, and if apt from
> >>> stable is affected or not. Given the recent dpkg, apt, and dbus changes
> >>> I think I'd rather let this as is, and wait in case it shows up again,
> >>> which should give us more information (due to the new apt not eating
> >>> dpkg's output).
> >>
> >> Noted, though I sincerely hope it is fixed. I /might/ be convinced to
> >> accept a .24 for this particular issue.
> >
> > Just to clarify, if there's still an issue, it's exclusively in apt.
> > The problems with dbus were due to apt trying to configure stuff when
> > libdbus was not yet properly configured (AFAIR). And there was similar
> > issues in apt between 0.9.9 and 1.0.7 (see #767734), but maybe this is
> > something else, although related, but only showing up when trigger
> > states are involved, this might also be a problem in apt in stable or
> > just with newer versions, that might have only emerged due to the
> > recent changes in dpkg. It might be that this only happens when
> > packages break on upgrade as it happened with some of the dbus
> > versions that failed on postinst, etc. Dunno, really.
> @deity/@dpkg: Right now, I am less concerned with "whose fault" it is
> and vastly more concerned with getting a functional upgrade path.
> If the correct fix is in APT and it can be provided in a "reviewable"
> diff in a reasonable time frame, I will happily take that. Otherwise,
> the "fix" needs to be in dpkg (despite being "wrong" or a revert). At
> this point in the freeze, we do not have the luxury of finding perfection.
Sorry, my point was that I don't think we know exactly what lead
to the dbus issue, which apt versions are affected, or if this is
actually something that showed up due to the trigger changes, dbus
maintscripts errors and if it was a latent issue that could as well
show up with a system crash leaving dpkg in a "broken" state, etc.
As I've mentioend before I don't mind at all adding a workaround in
dpkg if that provides a smooth upgrade path, but I'd like to do that
understanding what it's working around, and that it actually fixes
the issue, and not just blindly.
> The main issue for me is that besides this trigger issue, we also got
> the entire init system replacement on upgrades. I fear this is
> uncharted territories right now because "everybody" is (mostly) stuck
> behind these trigger issues.
While I think trigger cycles (be them real or bogusly detected as
the ones in 1.17.22) should be RC, they are actually recoverable
upgrade errors, as package involved in trigger cycles get reset into
half-configured, and their pending triggers reset. Which means that
a subsequent apt invocation should be able to continue from where it
was left off. So I don't think this has gotten people stuck on upgrade
problems (at least with dpkg >= 1.17.22).
The dbus problem seemed to be actually more severe, because although
«dpkg --configure --pending» seemed to be able to recover from the
situation, apt did not and got stuck there w/o being able to continue,
at least from the logs and comments in the bug reports, but not many
people have reported such issue so…
> > I also don't
> > know what's the stance on requiring specific packaging tools to be
> > upgraded first? Which might mean that if the issue is still there it
> > could be fixed in apt proper.
>
> (@deity: You may want to have a look at this as well)
>
> As I recall, it is not a requirement - but I believe we can recommend it
> in the release-notes. Although, with the Breaks being added to dpkg for
> trigger issues, you would quite possibly pull in additional upgrades
> along with it.
> By upgrading specific packaging tools, I presume you mean something like:
>
> """
> apt install -t jessie dpkg apt
>
> apt-get install -t jessie dpkg apt
>
> aptitude safe-upgrade -t jessie dpkg apt
> """
>
> (Depending on the frontend used). Assuming we add this to the release
> notes, is there any other packages you believe should be added to the
> list above?
If it's just a recommendation then I'm not sure that would be
satisfactory as we cannot rely on it. In any case for apt-based (or
cupt) frontends the important thing is to get the frontends upgraded
first, because dpkg ends up being invoked many times, and the new
version will be picked up once it gets upgraded. Also frontends seem
to favor Essential packages so they will get upgraded very early and
on its own dpkg run. But if something got to be added, then I guess
just requiring to upgrade apt or cupt would be enough.
Thanks,
Guillem
Reply to: