Skipping new-prerm failed-upgrade?
 

Hi,

to better understand this mail you can refer to this diagram
http://people.debian.org/~srivasta/MaintainerScripts.html#sec-3.4.3

During an upgrade from V1 to V2, if "V1->prerm upgrade V2" fails, dpkg tries
to run "V2->prerm failed-upgrade V1" and if it works the upgrade
continues normally.

This is very practical if V1 had a bug in its prerm script, it can be
worked around with some specific code in V2 and let the upgrade continue

Now there are cases where we really want to stop the upgrade from the
prerm. We have the case with dpkg where don't want to allow a downgrade
if we have packages that rely on a dpkg feature that the target version
does not support. For now it works because we did not have any prerm
in the old versions but as soon as you have a prerm you're screwed because
in general the scripts always "exit 0" for the failed-upgrade case.


I would thus like to discuss 2 ideas:

1/ I'd argue that in the case of downgrade, dpkg should not try to run
the failed-upgrade fallback because there's no way the oldest version
can be aware of how to work-around a problem in a prerm script of a
newer version that did not exist at the time the oldest prerm was
written.

Suggested patch attached. Do you agree with this? Do you see possible
problems with this?

2/ It would be nice to have a way for the prerm script to explicitly
disable the fallback. Maybe we could define a special exit code that
the "prerm upgrade" can use to tell dpkg to not consider the fallback.

Or do you see another way for the script to indicate this to dpkg?

If the exit code approach makes sense, what exit code could we use for
this?

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110618194847.GB11149@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110618194847.GB11149@rivendell.home.ouaza.com

Skipping new-prerm failed-upgrade?
 

Hi Raphael,

Raphael Hertzog wrote:

> 1/ I'd argue that in the case of downgrade, dpkg should not try to run
> the failed-upgrade fallback because there's no way the oldest version
> can be aware of how to work-around a problem in a prerm script of a
> newer version that did not exist at the time the oldest prerm was
> written.
>
> Suggested patch attached. Do you agree with this? Do you see possible
> problems with this?

The patch doesn't seem to be attached, but that makes perfect sense to
me. If the new prerm is failing for no good reason, a person can upgrade
to a version with the bug fixed and then downgrade.

> 2/ It would be nice to have a way for the prerm script to explicitly
> disable the fallback. Maybe we could define a special exit code that
> the "prerm upgrade" can use to tell dpkg to not consider the fallback.

That would defeat the point of having a fallback (namely avoiding bugs
putting systems into a state with no automatic way in the packaging
system to get out of it), so I think it's an awful idea. ;-) If you
can't trust the maintainers of future versions of your package, who
can you trust?

Thanks for working on this.
Jonathan


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110618205044.GA4096@elie">http://lists.debian.org/20110618205044.GA4096@elie

Skipping new-prerm failed-upgrade?
 

Hi,

On Sat, 18 Jun 2011, Jonathan Nieder wrote:
> Raphael Hertzog wrote:
> > 1/ I'd argue that in the case of downgrade, dpkg should not try to run
> > the failed-upgrade fallback because there's no way the oldest version
> > can be aware of how to work-around a problem in a prerm script of a
> > newer version that did not exist at the time the oldest prerm was
> > written.
> >
> > Suggested patch attached. Do you agree with this? Do you see possible
> > problems with this?
>
> The patch doesn't seem to be attached, but that makes perfect sense to
> me. If the new prerm is failing for no good reason, a person can upgrade
> to a version with the bug fixed and then downgrade.

Oops, sorry, it's here:
http://anonscm.debian.org/gitweb/?p=users/hertzog/dpkg.git;a=commitdiff;h=4bf0cb997ee46563fae8d43424 c8bd6fe6cd21cb

>
> > 2/ It would be nice to have a way for the prerm script to explicitly
> > disable the fallback. Maybe we could define a special exit code that
> > the "prerm upgrade" can use to tell dpkg to not consider the fallback.
>
> That would defeat the point of having a fallback (namely avoiding bugs
> putting systems into a state with no automatic way in the packaging
> system to get out of it), so I think it's an awful idea. ;-) If you
> can't trust the maintainers of future versions of your package, who
> can you trust?

Yeah, good point. And for upgrade it's the preinst that matters more, i.e.
for example when udev doesn't want to be upgraded because the kernel is
too old. And there there's no similar problem of fallback.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110619183850.GF20974@rivendell.home.ouaza.com">h ttp://lists.debian.org/20110619183850.GF20974@rivendell.home.ouaza.com

Skipping new-prerm failed-upgrade?
 

Raphael Hertzog <hertzog@debian.org> writes:

> I would thus like to discuss 2 ideas:

> 1/ I'd argue that in the case of downgrade, dpkg should not try to run
> the failed-upgrade fallback because there's no way the oldest version
> can be aware of how to work-around a problem in a prerm script of a
> newer version that did not exist at the time the oldest prerm was
> written.

> Suggested patch attached. Do you agree with this? Do you see possible
> problems with this?

I think I agree with this change. The only thing the old version could do
is run generic recovery code, and if there's generic recovery code, it can
just go into the new version directly where no fallback is required.

Downgrade is basically unspecified in Policy right now. It would be
interesting to do the work to specify how things behave, although I
suspect it would be a non-trivial amount of work.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87zkldvf2v.fsf@windlord.stanford.edu">http://lists.debian.org/87zkldvf2v.fsf@windlord.stanford.edu

Skipping new-prerm failed-upgrade?
 

Raphael Hertzog wrote:

> - maintainer_script_alternative(pkg, PRERMFILE, "pre-removal", cidir, cidirrest,
> - "upgrade", "failed-upgrade");
> + if (versioncompare(&pkg->available.version,
> + &pkg->installed.version) > 0) /* Upgrade */
> + maintainer_script_alternative(pkg, PRERMFILE, "pre-removal", cidir, cidirrest,
> + "upgrade", "failed-upgrade");
> + else /* Downgrade => no fallback */
> + maintainer_script_installed(pkg, PRERMFILE, "pre-removal", "upgrade",
> + versiondescribe(&pkg->available.version,
> + vdew_nonambig), NULL);

I suppose I would be happier with the condition being ">= 0", to make
it slightly more likely that the failed-upgrade code gets well tested
(though I don't think it matters much). Aside from that, looks very
sane. Thanks for thinking about these things.

Jonathan


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110620000444.GK23893@elie">http://lists.debian.org/20110620000444.GK23893@elie