From: Baurzhan Ismagulov <ibr@radix50.net>
To: isar-users <isar-users@googlegroups.com>
Subject: Re: [PATCH] buildchroot: Allow downgrades when installing packages
Date: Tue, 19 Mar 2019 11:10:01 +0100 [thread overview]
Message-ID: <20190319101001.GK16465@yssyq.m.ilbers.de> (raw)
In-Reply-To: <ad489b83-d3f6-0e6f-834d-d8a7e3152dc7@siemens.com>
On Mon, Feb 25, 2019 at 12:08:23PM +0100, Jan Kiszka wrote:
> Removing -rcX from a version string is lexically a downgrade, logically not.
> I'm not that sure if you can compensate this.
Debian uses tilde for that, e.g. 1.0~rc1-1+deb9u2. This is addressed in
https://www.debian.org/doc/debian-policy/ch-controlfields.html#version:
"First the initial part of each string consisting entirely of non-digit
characters is determined. These two parts (one of which may be empty) are
compared lexically. If a difference is found it is returned. The lexical
comparison is a comparison of ASCII values modified so that all the letters
sort earlier than all the non-letters and so that a tilde sorts before
anything, even the end of a part. For example, the following parts are in
sorted order from earliest to latest: ~~, ~~a, ~, the empty part, a. [7]
[7] One common use of ~ is for upstream pre-releases. For example,
1.0~beta1~svn1245 sorts earlier than 1.0~beta1, which sorts earlier than
1.0."
> Anyway, a real downgrade is a valid development scenario as well for our
> isar-apt.
Downgrade is supported by the packaging toolchain (dpkg / apt), but not by the
distribution (packages themselves, notably postinst, etc.).
https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_emergency_downgrading
says:
"Downgrading is not officially supported by the Debian by design. It should
be done only as a part of emergency recovery process. Despite of this
situation, it is known to work well in many incidents. For critical systems,
you should backup all important data on the system after the recovery
operation and re-install the new system from the scratch.
You may be lucky to downgrade from newer archive to older archive to recover
from broken system upgrade by manipulating candidate version..."
So I'd be reluctant to do that by default. What about extracting the apt
options into a config file, where the user may add his options?
With kind regards,
Baurzhan.
next prev parent reply other threads:[~2019-03-19 10:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-23 10:44 Jan Kiszka
2019-02-25 9:39 ` Henning Schild
2019-02-25 9:57 ` Jan Kiszka
2019-02-25 10:15 ` Henning Schild
2019-02-25 11:08 ` Jan Kiszka
2019-03-19 10:10 ` Baurzhan Ismagulov [this message]
2019-03-19 10:31 ` Jan Kiszka
2019-03-19 17:33 ` Maxim Yu. Osipov
2019-03-19 18:46 ` Jan Kiszka
2019-03-04 9:04 ` Claudius Heine
2019-03-04 9:08 ` Jan Kiszka
2019-03-28 12:42 ` Maxim Yu. Osipov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190319101001.GK16465@yssyq.m.ilbers.de \
--to=ibr@radix50.net \
--cc=isar-users@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox