Bug#952703: [cryptsetup] needs breaks on old cryptsetup-bin
On Fri, 2020-02-28 at 16:41 +0100, Guilhem Moulin wrote: > On Fri, 28 Feb 2020 at 05:40:10 +, jnq...@gmail.com wrote: > > As I wrote previously, adding the break isn't the only thing that > would > have made your upgrade you smooth, the postinst script would like > need > to be adapted too. > > While the side effect isn't intentional, not having the Breaks: on > older > cryptsetups causes dpkg to fail, which I'd argue is better than > ending > up with a broken (unbootable) systems. Sure, we could test upgrade > paths from very old src:cryptsetups, but I'm not personally > interested > in working on something that we as a project don't support. Not keen > about the extra clutter either. So right now I'm leaning towards > closing this as ‘wontfix’. :-P Ok. Fair enough :)
Bug#952703: [cryptsetup] needs breaks on old cryptsetup-bin
On Fri, 28 Feb 2020 at 05:40:10 +, jnq...@gmail.com wrote: > edit: ah, so I see there were two reorganisations, one in June 2018 and > one more in June 2019... More precisely, one two-steps reorganisation with a Debian release in between ;-) > Indeed if I had performed a stable->stable->stable upgrade then I would > not have encountered the error. I only question whether limiting > upgrade compatibility so strictly is the best idea. Especially when a > couple of breaks entries is a such a tiny things for a package to carry > and enhances robustness. As I wrote previously, adding the break isn't the only thing that would have made your upgrade you smooth, the postinst script would like need to be adapted too. While the side effect isn't intentional, not having the Breaks: on older cryptsetups causes dpkg to fail, which I'd argue is better than ending up with a broken (unbootable) systems. Sure, we could test upgrade paths from very old src:cryptsetups, but I'm not personally interested in working on something that we as a project don't support. Not keen about the extra clutter either. So right now I'm leaning towards closing this as ‘wontfix’. :-P -- Guilhem. signature.asc Description: PGP signature
Bug#952703: [cryptsetup] needs breaks on old cryptsetup-bin
On Fri, 2020-02-28 at 02:43 +0100, Guilhem Moulin wrote: > On Thu, 27 Feb 2020 at 23:55:49 +, jnq...@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 Oh, Okay. I recalled it being much sooner than that, time flies :) edit: ah, so I see there were two reorganisations, one in June 2018 and one more in June 2019... > 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 > > > 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 Sure, but I was just copying the apt lists and cached packages from my proper up-to-date sid system to a USB pendrive to make use of in the old live sid environment on this other system I was working on. > > 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. Okay, I can accept that :P. And I can accept that adjusting my thinking to relate an old sid install with how it maps to stable releases and do stepped upgrades could be sensible. > > edit: I just tried looking up Debian policy regarding
Bug#952703: [cryptsetup] needs breaks on old cryptsetup-bin
On Thu, 27 Feb 2020 at 23:55:49 +, jnq...@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. signature.asc Description: PGP signature
Bug#952703: [cryptsetup] needs breaks on old cryptsetup-bin
On Thu, 2020-02-27 at 22:44 +0100, Guilhem Moulin wrote: > Control: retitle -1 unsupported upgrade from Control: severity -1 minor > > On Thu, 27 Feb 2020 at 20:33:54 +, 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
Bug#952703: [cryptsetup] needs breaks on old cryptsetup-bin
Control: retitle -1 unsupported upgrade from ``` > 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 -- Guilhem. signature.asc Description: PGP signature
Bug#952703: [cryptsetup] needs breaks on old cryptsetup-bin
Package: cryptsetup Version: 2:2.2.2-3 I've noticed that selectively trying to just upgrade the cryptsetup package via `aptitude upgrade cryptsetup` fails with the following dpkg error: ``` 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 ``` I expect you forgot to place a suitable breaks on the older packages after the reorganisation. I experienced this running the above command whilst updating cryptsetup in a live-disc environment that has a much to old version (don't worry my actual installs are uptodate!). 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.
