On Mon, 14 Mar 2022 13:52:14 +0000, Holger Levsen <hol...@layer-acht.org> wrote: > On Mon, Mar 14, 2022 at 01:10:19PM +0000, Wookey wrote: > > > You're trying to produce packages from CI builds or other automation > > > where you sometimes have native Debian revisions. > > > > > > * you are producing a package where you have distinct upstream and > > > debian branches, and you cannot control the upstream version number. > > > > > > > Doesn't this make it 'not a native debian package'? > > yes, exactly, that's the problem. > > > I thought the whole point of debian native packages was that there was > > no 'upstream' and it was only for debian so you _are_ in control of > > the source, the versioning and the releases? > > yes, that was the idea when native packages were introduced over > 20 ago, when there were hardly any Debian forks, and certainly no > CI systems and other automated systems which 'constantly fork'. > > > As soon as that stops > > being true then should one not shift to making it a standard > > 'upstream+debian revision' non-native package? > > yes, we should convert all native packages in our archive, > the idea of a native package has been obsoleted for long.
I think there are still some cases where it makes sense, e.g. for “meta-source” packages where the upstream is really another package (e.g. binutils-mingw-w64 and friends). Suffixes for downstreams work fine, see https://launchpad.net/ubuntu/+source/gdb-mingw-w64 for one instance. Regards, Stephen
pgpf7WU3HcrNr.pgp
Description: OpenPGP digital signature
