[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1007717: Native source package format with non-native version

Felix Lechner <felix.lechner@lease-up.com> writes:
> On Tue, Mar 15, 2022 at 9:33 PM Russ Allbery <rra@debian.org> wrote:

>> We should define native and non-native packages in terms of version
>> numbers, and allow both native and non-native packages to use
>> single-tarball source package formats.

> I co-maintaintain several Debian-internal tools, and that description is
> backwards. "Native" sources are characterized by their lack of Debian
> patches.

This is exactly the semantic confusion that I believe is wrong and we
should undo.  "Native" vs. "non-native" should be a property of the
relationship between the package and a separate upstream release, which is
represented in the version.  That should be decoupled from the source
package format.

The point that Ian and Sam are raising is that a single tarball is a good
way of representing the Debian package source in several non-native cases
where we are still packaging a piece of software with an independent
upstream existence, and where having a version with a Debian revision is
still semantically correct.

> On that note, the term "native" is also not great. The words "patched"
> and "unpatched" describe the relationship between sources in the archive
> and their respective upstreams more accurately.

I think that would add even more confusion.  It's very common for
non-native packages to switch between patched and unpatched from upload to
upload, depending on whether Debian has to carry additional patches,
without any change in their version number format or in the source package
format.  This is correct and should continue to be supported.

Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

Reply to: