Bug#1040477: librust-syn-1-dev fails to coinstall
Hi Peter and Fabian, On Thu, Jul 06, 2023 at 01:27:19PM +0200, Helmut Grohne wrote: > Package: librust-syn-1-dev > Version: 1.0.109-2 > Severity: serious > Justification: fails to (co)install > Control: affects -1 + src:rust-fd-find > User: debian-cr...@lists.debian.org > Usertags: ftcbfs > X-Debbugs-Cc: de...@lists.debian.org > > librust-syn-1-dev has (among other things) the following metadata: > > Provides: librust-syn-1.0.109-dev > Breaks: librust-syn-1.0.109-dev > Multi-Arch: same > > It is not clear to me what this is supposed to mean. Can you shed some > light on what this is supposed to achieve? > > In any case, apt and dpkg disagree about what this shall mean. apt > thinks that self-breaks are to be ignored and asks dpkg to configure > both of these packages, but dpkg doesn't like that: > > | dpkg: dependency problems prevent configuration of librust-syn-1-dev:amd64: > | librust-syn-1-dev:arm64 (1.0.109-2) breaks librust-syn-1.0.109-dev and is > unpacked but not configured. > | librust-syn-1-dev:amd64 (1.0.109-2) provides librust-syn-1.0.109-dev. > | > | dpkg: error processing package librust-syn-1-dev:amd64 (--configure): > | dependency problems - leaving unconfigured > > You can reproduce the installation failure using: > > mmdebstrap unstable /dev/null --architectures=amd64,arm64 --variant=apt > --include=librust-syn-1-dev:amd64,librust-syn-1-dev:arm64 > > If apt and dose were refusing this situation this were a normal bug at > best. But since dpkg fails badly and leaves the system in an > inconsistent state, I am raising this to rc-severity. Even if we deem > this to be an apt bug or dpkg bug in the end, librust-syn-1-dev must > still be changed since we cannot depend on fixed versions of package > managers being used to install packages. This problem, which is reported almost a month ago still persists. I am aware that a generic solution is hard to come by and I need to be patient for a full solution. On the flip side, the current metadata causes dpkg and dose to disagree. This in turn causes https://crossqa.debian.net to believe that there is a temporary problem with the archive as a whole. It thus ceases testing further packages until the next mirror push. This behaviour is very useful in cases where there are M-A:same skews as those tend to affect very many packages. Since rust-syn appears in more and more packages Build-Depends, this particular bug effectively disableds cross compilation testing now as crossqa.d.n tests a few packages until it runs into an affected one and throttles itself. Is there any chance we could have a temporary workaround for this issue? A very simple workaround from my pov would be temporarily removing Multi-Arch: same. Of course that would make the package unavailable to cross compilation, but on the flip side, it already is. After dropping Multi-Arch: same, dose would no longer consider solutions involving coinstallations of it and archive testing could continue. Failing that, the only way I see is blacklisting the package in crossqa, but then I'd probably forget about it and it would also be surprising in the diagnostics as crossqa would always tell that this package does not exist. I prefer having you work around the issue. A simple upload dropping M-A:same removes the worst of pain and gives us time to work on a generic solution. Do you agree? Helmut
Bug#1040477: [Pkg-rust-maintainers] Bug#1040477: Bug#1040477: librust-syn-1-dev fails to coinstall
On Thu, Jul 06, 2023 at 04:39:08PM +0100, Peter Green wrote: > > I'd be very interested in knowing what this self-conflict is supposed to > > achieve. > > It is common upstream for there to be multiple semver-incompatible versions > of each rust crate in use at a given time. Incompatibilities can range from > minor corner cases that are easily patched away to complete redesigns > > We try to only package one version of each crate at a time, but sometimes > that isn't practical. When it becomes impractical we crate semver-suffix > packages. The convention in the rust team is that the un-suffixed packages > are used for the latest version and suffixed versions are used for any > older versions. > > When packaged crates are installed on a Debian system. They are installed > in a path that depends on the upstream version of a crate. > > This creates a problem though, if the same version is packaged as both > a non-suffixed and suffixed version. Something that happens fairly > frequently when a new version is introduced e.g. > > Before: > > librust-foo-dev version 1.23-1 > > After: > > librust-foo-1-dev version 1.23-2 > librust-foo-dev version 2.34-1 > > This doesn't always happen, indeed it didn't happen in the case of syn, > because a new upstream release of syn 1.x at the same time at the same > time the semver suffix was introduced. However debcargo works on one > crate at a time. so it doesn't know if this has happened or not. > > When this happens, it leads to a file conflict. In an attempt to fix > this breaks+replaces were added. Unfortunately these proved to be > insufficient because while breaks against virtual packages work, > replaces apparently don't. We are in the process of considering > several options to fix this, but overall switching to conflicts+replaces > seems the least likely to be problematic. > > Do you encounter the same problem if you replace the breaks with > conflicts? if so we would need to do something about it. I think > the easiest would probablly be to put a version constraint on the > conflicts/replaces. It would mean we would have to take care that > semver-suffixed packages had a higher Debian revision than their > un-suffixed counterparts, but I think that is managable. and, with a bit of unexpected delay (sorry), the result of a discussion Helmut and me had in parallel on IRC: the issue with Conflicts arises in combination with M-A:same, since dpkg and apt don't agree on which one of those two "angles" has higher priority. to sort that out would require a release cycle or two. it seems like this leaves the other alternative from #1034939 [0, CC-ed], namely, switching the breaks and replaces to point at the real package (version guarded), so that upgrading from "old" non suffixed package (for which a newer version should exist by definition if a suffixed package of the same version exists) while installing the suffixed package of the same "old" version at the same time works. the main downside (and reason why we preferred the Conflicts-based variant) is that this means that two suffixed packages with different versions are no longer co-installable (since the one with the higher version would break the older one). thankfully, such issues should seldomly matter in practice. or we could investigate just switching the replaces, and keeping the breaks as is. 0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034939
Bug#1040477: [Pkg-rust-maintainers] Bug#1040477: librust-syn-1-dev fails to coinstall
I'd be very interested in knowing what this self-conflict is supposed to achieve. It is common upstream for there to be multiple semver-incompatible versions of each rust crate in use at a given time. Incompatibilities can range from minor corner cases that are easily patched away to complete redesigns We try to only package one version of each crate at a time, but sometimes that isn't practical. When it becomes impractical we crate semver-suffix packages. The convention in the rust team is that the un-suffixed packages are used for the latest version and suffixed versions are used for any older versions. When packaged crates are installed on a Debian system. They are installed in a path that depends on the upstream version of a crate. This creates a problem though, if the same version is packaged as both a non-suffixed and suffixed version. Something that happens fairly frequently when a new version is introduced e.g. Before: librust-foo-dev version 1.23-1 After: librust-foo-1-dev version 1.23-2 librust-foo-dev version 2.34-1 This doesn't always happen, indeed it didn't happen in the case of syn, because a new upstream release of syn 1.x at the same time at the same time the semver suffix was introduced. However debcargo works on one crate at a time. so it doesn't know if this has happened or not. When this happens, it leads to a file conflict. In an attempt to fix this breaks+replaces were added. Unfortunately these proved to be insufficient because while breaks against virtual packages work, replaces apparently don't. We are in the process of considering several options to fix this, but overall switching to conflicts+replaces seems the least likely to be problematic. Do you encounter the same problem if you replace the breaks with conflicts? if so we would need to do something about it. I think the easiest would probablly be to put a version constraint on the conflicts/replaces. It would mean we would have to take care that semver-suffixed packages had a higher Debian revision than their un-suffixed counterparts, but I think that is managable.
Bug#1040477: librust-syn-1-dev fails to coinstall
Hi, Quoting Helmut Grohne (2023-07-06 13:27:19) > librust-syn-1-dev has (among other things) the following metadata: > > Provides: librust-syn-1.0.109-dev > Breaks: librust-syn-1.0.109-dev > Multi-Arch: same this looks very bad. > If apt and dose were refusing this situation this were a normal bug at > best. But since dpkg fails badly and leaves the system in an > inconsistent state, I am raising this to rc-severity. Even if we deem > this to be an apt bug or dpkg bug in the end, librust-syn-1-dev must > still be changed since we cannot depend on fixed versions of package > managers being used to install packages. I'd be very interested in knowing what this self-conflict is supposed to achieve. Depending on the answer it might be worth adding a Lintian check so that this doesn't happen again in the future. Thanks! cheers, josch signature.asc Description: signature
Bug#1040477: librust-syn-1-dev fails to coinstall
Package: librust-syn-1-dev Version: 1.0.109-2 Severity: serious Justification: fails to (co)install Control: affects -1 + src:rust-fd-find User: debian-cr...@lists.debian.org Usertags: ftcbfs X-Debbugs-Cc: de...@lists.debian.org librust-syn-1-dev has (among other things) the following metadata: Provides: librust-syn-1.0.109-dev Breaks: librust-syn-1.0.109-dev Multi-Arch: same It is not clear to me what this is supposed to mean. Can you shed some light on what this is supposed to achieve? In any case, apt and dpkg disagree about what this shall mean. apt thinks that self-breaks are to be ignored and asks dpkg to configure both of these packages, but dpkg doesn't like that: | dpkg: dependency problems prevent configuration of librust-syn-1-dev:amd64: | librust-syn-1-dev:arm64 (1.0.109-2) breaks librust-syn-1.0.109-dev and is unpacked but not configured. | librust-syn-1-dev:amd64 (1.0.109-2) provides librust-syn-1.0.109-dev. | | dpkg: error processing package librust-syn-1-dev:amd64 (--configure): | dependency problems - leaving unconfigured You can reproduce the installation failure using: mmdebstrap unstable /dev/null --architectures=amd64,arm64 --variant=apt --include=librust-syn-1-dev:amd64,librust-syn-1-dev:arm64 If apt and dose were refusing this situation this were a normal bug at best. But since dpkg fails badly and leaves the system in an inconsistent state, I am raising this to rc-severity. Even if we deem this to be an apt bug or dpkg bug in the end, librust-syn-1-dev must still be changed since we cannot depend on fixed versions of package managers being used to install packages. Helmut
