Re: proposed MBF: packages still using source format 1.0
On Thu, 2022-03-10 at 12:09:14 -0700, Sam Hartman 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.
> You want to do everything in git, and not have to deal with quilt
> patches.
> Say you don't even have any patches, but you sometimes do produce new
> revisions simply for changes to debian control files and the like.
As I mentioned last time around, it has never been made clear why a
different “revision”-separator character cannot be used here. (Perhaps
out of doctrine? :)
> * You are trying to local (or downstream) builds of debian packages that
> do have debian revision numbers.
> You want to do everything in git because honestly dealing with dscs is
> a PITA and if you can avoid it you want to.
> You need to produce dscs to feed to sbuild, or mini-buildd or something.
> But you just want to do that easily from your git CI pipelines.
>
> My frustrations with the number of hours I've lost because of this
> doctrinal issue has caused me to come close to giving up on Debian more
> than once.
> Part of that is frustration around how the change was handled and how
> concerns and use cases where not considered and dismissed without
> consideration.
> But part of that is how I've had to hack around the isue in every
> downstream CI environment where I took Debian packages and modified
> them.
In this second scenario, you seem to be using .dsc in anger, when you
don't really want to have to be using them at all. And when doing that
you seem to have decided that using them in a way that makes our packaging
stack more confusing, incoherent and error-prone is better, than say
trying to get those other tools to avoid using the .dsc format at all.
The other thing, is that people keep confusing the transport source
format (.dsc, etc.), with the unpacked source. Of course it is not
helped that dpkg-source seems to be conflating these, but this is not
really the case. I've for example been pondering adding an extract
mode where instead of generating a quilt .pc/ compatible directory it
would instead generate a git repo. There's also the «3.0 (custom)»
format, which exemplifies this detachment.
But in any case, in your second scenario, if you are doing CI builds,
and only want to be working with git, you could simply do something
like this from your git checkout:
$ dpkg-source --format="3.0 (git)" --build source-dir-4.0/
regardless of the declared source format in the unpacked tree
(including 1.0, 2.0 or any 3.0 format). For binary builds you could
do:
$ dpkg-buildpackage --source-option=--format="3.0 (git)" -us -uc
Regards,
Guillem
Reply to: