public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
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.

  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