Guillem Jover: > [..] > > We discussed this briefly yesterday on IRC before Ximin filed the > report. I don't see much difference with what was mentioned and I'll > repeat what David Kalnischkies and me proposed on the spot, as a > potentiall working solution. >
To be fair, neither of you were very specific and the words you said could just have as easily described what we were already doing previously, which is how I interpreted it at the time. > [..] > > So you could have package slab-X.Y and then depend on just that, or if > for some reason you need to have coinstallability down to the minor > version, then slab-X.Y.Z, in which case that package would provide > slab-X.Y (= X.Y.Z). In addition, all of these would also provide > slab-X (= X.Y.Z) and slab (= X.Y.Z) and probably also slab, so that > you can represent all the range types. > > Cargo deps (A) dpkg deps (A-X.Y || A-X.Y.Z) > A A > A (>= 6) A (>= 6) > A (>= 6.1) A (>= 6.1) > A (>= 6.1.3) A (>= 6.1.3) > A (>= 6, << 7) A-6 > A (>= 6.1, << 6.2) A-6.1 > A (= 6) A-6 > A (= 6.1) A-6.1 > Thanks for being specific here. After thinking after it for a bit, I think this might work. The key is to only generate a single item within in the comma-separated list of AND-clauses in the dpkg dependency, where the item itself is a "|"-separated OR-clause. It would be pretty ugly in some circumstances: Cargo deps dpkg deps A (>= 6.1, << 9.5) ----> A-6 (>= 6.1) | A-7 | A-8 | A-9 (<< 9.5) but I think I have a decently-simple way of achieving this in debcargo. > [..] >> In the Debian Rust team, we previously experimented with e.g. converting: >> >> - Cargo dependencies X (>= 6, << 7) into dpkg dependencies X-6 | X-7 >> - Cargo dependencies X (>= 6) into dpkg dependencies X-6 | X-7 | X-8 | >> X-9 | X-10 > > That seems indeed wrong. At least the first should have been just X-6, > and yeah the second should have used more granular versioned provides > as shown above. > The first was a typo, and as for the second I did not realise by "granular" you meant Provides both X (= 6) and X-6 (= 6) etc, I thought you meant just the latter which is what we were already doing. >> [..] >> >> So the cleanest solution to this problem would be to support two-sided >> version >> ranges. This would be beneficial across the whole archive as well - I have >> needed to do the Depends: X (>= 4), X (<< 5) hack before when what I really >> meant was (>= 4, << 5), and I remember this in others' packages too. > > Depends on how you define cleanest. :) In this case that means you > cannot use this anyway until a stable+1 (assuming just dpkg and apt > implemented this right away), and it would not be usable anyway until > most major dependency parsers/satisfiers would support it too, which > might be stable+2, perhaps. > If you guys implement it, I'd be happy to switch to it after 2 stable releases, that's only 4 years and I'm sure Rust will be around for a long time. The fact that it's so hard means there's a load of technical debt there that is worth trying to pay back anyways. > Of course the counter-proposal that David and me provided assumes the > versions have sane semantics (similar to semver), and that their > format is uniform all over Cargo. If that's not the case then that > might be a problem, if you are converting the dependencies > automatically. :) > Yes luckily it's uniform enough. semver actually has very specific semantics to do with API compatibility, but we don't even need to rely on that here, we just need that the version numbers are constrained enough to be able to do this Provides: A (= X.Y.Z) A-X (= X.Y.Z) A-Y (= X.Y.Z) thing. I think the only way to sustainably do it long-term is to automatically generate it. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
