[pkg-cryptsetup-devel] Bug#952703: [cryptsetup] needs breaks on old cryptsetup-bin

[Guilhem Moulin]

On Thu, 27 Feb 2020 at 23:55:49 +0000, jnqnfe at gmail.com wrote:
> It is thus not a question of 'FrankenDebian' but of how old a sid
> installation upgrading is supported for.

The starting baseline doesn't matter, if you start from sid and don't
upgrade for longer than a full recycle, then most of your packages are
likely to be as old as the ones in oldstable.  Mixing stable and sid
packages is asking for trouble, but at least the upgrade path from
stable to sid is tested (the package in sid will be transitioning to
testing, which is stable +1); upgrading from *old*stable to testing/sid
is not, regardless whether if it's a selective or full upgrade.

> I don't think too much focus should be paid to the fact of just how old
> the version is in this case. Surely this affects all sid/testing
> installations that have not been upgraded since the reorganisation of
> cryptsetup began (~May 2019), and became an issue at some point towards
> the end of the reorganisation, which nobody encountered or bothered to
> report until now.

We started the package split in *June 2018* with 2:2.0.3-1, and ended July
2019 with 2:2.1.0-6.  Between the two buster was released, and it ships
2:2.1.0-5 (+deb10u2 right now).  So your upgrade leaps over a debian
stable release, which is not something supported.  If you had upgraded
from stretch's cryptsetup to buster's *and then* to bullseye/sid's, and
the upgrade path had broken, then I would have raised the severity to RC.

> Also, big upgrades, such as stretch-> buster do not always go cleanly,
> for which users may resort to performing some degree of selective
> upgrades in their upgrade path. Would they not potentially run into
> this error doing `aptitude upgrade cryptsetup` in that situation for
> such a stretch to buster upgrade in this case?

No, that's stable → stable+1 so fully supported.

FYI you don't even need bullseye/sid's cryptsetup for LUKSv2.  It's even
mentioned in buster's release notes:
https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.en.html#cryptsetup-luks2

> I think it should be simple policy that when things get moved about
> between packages, that a breaks is specified for the older versions to
> prevent such dpkg file-clash errors that could occur in situations such
> as selective upgrades, and remains permanently in place for a
> reasonable number of years to avoid any issues for a reasonably wide
> range of scenarios.

And that's what we did, except that we count in release cycles not in
years.  Passed a full release cycle we decided to drop the clutter,
because going from oldstable to testing (or stable to stable+2), i.e.
skipping an upgrade, has never been something supported.  This is
something stated in each release note, see for instance

    “Direct upgrades from Debian releases older than 9 (stretch) are not
     supported. Please follow the instructions in the Release Notes for
     Debian 9 to upgrade to Debian 9 first.”
    — https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.en.html

Or 

    “Please always upgrade to Debian Testing from current stable.
    Upgrading from oldstable is not supported and might encounter
    unexpected errors.”
    — https://wiki.debian.org/DebianTesting

Also, the package relationship isn't the only thing to care about when
upgrading.  There are also warning for deprecated settings which are
later removed, compatibility symlinks, etc.  Skipping (Debian) releases
upon upgrades has never been something supported, and we decided to
simply remove the clutter.  For the same reason we might just close this
as ‘wontfix’.

> I expected that a simple oversight had been made at the time the
> cryptsetup reorganisation was done, though your focus on upgrade paths
> suggests otherwise, that you perhaps do not give as much consideration
> to supporting sid & testing installations as stable ones?

Uh?  testing will be the next stable, so we're very careful about what
goes inside.  And same thing for sid.  Sorry, a sid system deployed
before stretch was released, with a direct (selective or full) upgrade
to sid isn't a sid system, that's very much a FrankenDebian.

> edit: I just tried looking up Debian policy regarding sid/unstable and
> breaks info. I came across 
> https://www.debian.org/doc/debian-policy/ch-relationships.html, but
> nothing specific about 'sid'/'unstable' was mentioned, nor in fact
> 'stable'... nor in https://www.debian.org/doc/debian-policy/

We have proper package relationship in place to support upgrading from
stretch to buster (or more precisely, from ≥2:1.7.3-4, <2:2.1.0-5 to 2:2.1.0-5)
and others fro buster to bullseye/sid (or more precisely, from
≥2:2.1.0-5, <2:2.2.2-3 to 2:2.2.2-3, or whichever version we'll ship to
bullseye). 

-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20200228/2b6bcf00/attachment.sig>