Re: proposed MBF: packages still using source format 1.0
>>>>> "Guillem" == Guillem Jover <guillem@debian.org> writes:
Guillem> 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.
Guillem> As I mentioned last time around, it has never been made
Guillem> clear why a different “revision”-separator character cannot
Guillem> be used here. (Perhaps out of doctrine? :)
Often that works.
It's kind of strange though to have to change revision characters
depending on the releases.
For example I've been in situations
where releases were built from tarballs and were not native, but
betas and other upstreams were built directly from git and thus were
native.
So some revisions had + as a revision character and some had dash.
But also, let's imagine it were doctrin.
Policy should decide that kind of doctrin not dpkg.
>> * 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.
Guillem> In this second scenario, you seem to be using .dsc in
Guillem> anger, when you don't really want to have to be using them
Guillem> at all. And when doing that you seem to have decided that
Guillem> using them in a way that makes our packaging stack more
Guillem> confusing, incoherent and error-prone is better, than say
Guillem> trying to get those other tools to avoid using the .dsc
Guillem> format at all.
And I'd be a lot less frustrated if the work to get these other tools
not to need dscs and been done *before* the workflow that everyone was
using at the time was broken by the dpkg maintainer.
Reply to: