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, jnq...@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
