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

[jnqnfe at gmail.com]

On Thu, 2020-02-27 at 22:44 +0100, Guilhem Moulin wrote:
> Control: retitle -1 unsupported upgrade from <buster to bullseye
> Control: severity -1 minor
> 
> On Thu, 27 Feb 2020 at 20:33:54 +0000, jnqnfe at gmail.com wrote:
> > ```
> > dpkg: error processing archive
> > /var/cache/apt/archives/cryptsetup_2%3a2.2.2-3_deb (--unpack):
> > trying to overwrite '/usr/sbin/luksformat', which is also in
> > package
> > cryptsetup-bin 2:1.7.0-2
> > ```
> 
> That seems to be an upgrade from a package version even older that
> stretch's (stretch has 2:1.7.3-4) all the way to bullseye's.  That's
> not
> a supported upgrade path.  The only supported one is stable →
> stable+1
> (for which we have suitable Breaks relations in place),
> https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian
> .
> 
> > I expect you forgot to place a suitable breaks on the older
> > packages
> > after the reorganisation.
> > […]
> > Clearly what should be expected from a targetted upgrade specifying
> > just `cryptsetup` and not `cryptsetup cryptsetup-bin
> > cryptsetup-initramfs` should be that it either pulls in all three
> > as
> > necessary upgrades or at least complains about version conflicts.
> > It
> > should never just fail like this.
> 
> I suppose adding Breaks on pre-Buster packages won't hurt so I'm
> keeping
> that open (with a lower severity) but you're very much on your own
> once
> you start mixing releases like this :-P

Hi :),

Actually the live-disc I'm using is sid based (a custom one built with
live-build), so this is actually a partial sid upgrade (cryptsetup
only). It is thus not a question of 'FrankenDebian' but of how old a
sid installation upgrading is supported for.

(replacing my live-disc with a new one is an obvious point you might
make, but that's easier said than done as I'll mention later and is
somewhat besides the point).

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. While most sid installations are probably kept up-to-
date regularly, there are those, like live-discs, that can be outdated.

For instance:
 - the live environment of a live-disc, as just mentioned.
 - live-build built discs can include the Debian installer, which can
be the sid version of d-i, which can create new sid-based
installations, which then need upgrading after installation. (again,
see later regarding replacement of old live-discs).
 - I recently had to deal with a Debian sid installation using
unattended-upgrades for which a mistake in the config for unattended-
upgrades meant that upgrades had not occurred in months. :/

Selective package upgrades of such an old installation might be rare,
but sometimes it might be done to gain an important improvement, like
adding luks v2 support for an old live-disc (again, see later regarding
replacement of custom live-discs).

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?

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. 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?

fyi, the reason for my using such an old live-disc (whilst I would
agree it to be good policy to replace them at least yearly) relates to
bug #718225. live build bug #718225 is about how live-build insecurely
downloads some files by not authenticating them, which means that it is
not secure to build a live-disc from public mirrors, only from local
copies of a mirror. Building a local mirror is not ideal for many
people (consider the much larger amount of data needed to be
downloaded). I have previously built a patchset for #718225 which was
never merged with which I built my last live-disc and I am currently in
the process of rebasing and reworking a lot of old live-build work in
the hope of both getting a lot of it finally merged and of using it to
make myself a new disc. Until then I'm not in a position of (securely)
replacing my old one. (I guess I could download the official one for
the time being, but I'd be doing this work on live-build to make my own
anyway). Right now I'm using that old live-disc to do something with a
system with a luks v2 encrypted volume and so I needed to selectively
upgrade the cryptsetup package of that live environment (a cdrom, not a
USB installation which could be fully upgraded) via a USB stick, and I
encountered the reported error.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718225

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/

Regards,
Lyndon Brown