(Please do not CC me for list mails, I'm subscribed. Thanks.)
Am 14.02.26 um 22:15 schrieb Simon Josefsson: > And v7, v8, ...? That is a lot of new packages, for something where we > ideally would ever ship only the latest version of a package. I don't really see a problem here. First of all, I don't think that there are many upstreams which have several -vX iterations on their packages. I don't have any numbers, though. Also, we could remove all vX packages which are no longer used by any reverse dependencies. I think the main benefit is that we don't *need* a mini transition and patching of all reverse dependencies by separating the v4 and v5 packages in distinct namespaces. >> Also, if I understand it correctly, it's more or less the same amount of >> work -- just the other way round, right? Either we create a new package >> with -v5, or we update the existing (versionless >> golang-github-jackc-pgx) package to v5 and introduce a -v4 package for >> the remaining reverse dependencies which cannot be upgraded yet. > > Yes, that is probably why that approach has been used a couple of times > in the past. However, I think the problem is when future new version > appears, then we are looking at exploding the number of packages. > > If we keep golang-github-jackc-pgx for latest upstream, and the > occasional golang-github-jackc-pgx-vX for old versions when there is no > feasible way to upgrade some dependent package, the total number of > packages are reduced over time. See above, I don't think "exploding number of packages" is describing the reality. Again: I fail to see how package names with a version suffix would massively increase the number of packages, while an approach without a version suffix for the latest upstream (plus version suffixes for previous, still needed versions) would not increase that number. Let me construct an example: Package A, B, C need golang-lib-dev. That is a package without a version suffix, currently at version 4. The left side of the table is "your" suggestion, the -dev package always tracks the latest upstream version, previous releases (if needed) get a suffix. The right side of the table is "my" suggestion, the (legacy) -dev package at version 4 stays at that version and we introduce new packages with a version suffix. -dev is latest version | -dev is v4, then suffixes =======================|========================== A: golang-lib-dev | A: golang-lib-dev B: golang-lib-dev | B: golang-lib-dev C: golang-lib-dev | C: golang-lib-dev This would require one source and binary package. Now golang-lib-dev gets updated to v5, and package A and B use that version, package C cannot be upgraded: -dev is latest version | -dev is v4, then suffixes =======================|========================== A: golang-lib-dev | A: golang-lib-v5-dev B: golang-lib-dev | B: golang-lib-v5-dev C: golang-lib-v4-dev | C: golang-lib-dev This would require two source and binary packages in both suggestions, although they would have different names. Now golang-lib-dev gets updated to v6, and only package A can use that version, package B cannot use it, and package C is still stuck at v4: -dev is latest version | -dev is v4, then suffixes =======================|========================== A: golang-lib-dev | A: golang-lib-v6-dev B: golang-lib-v5-dev | B: golang-lib-v5-dev C: golang-lib-v4-dev | C: golang-lib-dev Now we would need three source and binary packages in both suggestions. Please note that the calculation would still be the same if *all* packages could be upgraded to the latest version of golang-lib-dev. Then we package golang-lib-v6-dev and remove golang-lib-v5-dev. Regards, Tobias
OpenPGP_signature.asc
Description: OpenPGP digital signature
