Re: proposed MBF: packages still using source format 1.0
>>>>> "Steve" == Steve McIntyre <steve@einval.com> writes:
Steve> Ian Jackson wrote:
>>
>> 1. Why is 1.0-without-diff not always worse than 3.0 (native) ?
>>
>> 1.0 native is sometimes better than 3.0 (native) because
>> dpkg-source refuses to build a 3.0 native package with a Debian
>> revision in its version number.
>>
>> This prohibition exists solely because of a doctrinal objection
>> to native-format packages with Debian revisions. There is no
>> technical reason why this restriction could not be lifted. I
>> sometimes upload this way and I have never had anyone report
>> problems[1] with it.
>>
>> IMO there is nothing wrong with native format packages with
>> Debian revisions. They work just fine. For a small paockage,
>> this is often a good choice, because it avoids dealing with
>> patches at all.
Steve> Why on earth *would* you mess around using Debian revisions
Steve> on a native-format package, though?
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.
* 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.
Reply to: