Re: git-buildpackage and tarballs
Charles Plessy <plessy@debian.org> writes:
> I think that we are discussing two separate questions: whether a
> maintainer of his own software in Debian should release a new upstream
> version when updating the Debian package, and whether the the maintainer
> of a Debian package for which there is no upstream tarball can use a
> native format or not.
I see those two issues as linked because of how version numbering works,
which is the key difference in using the native format. With a native
package, you only have a single version number, not a version with a
Debian revision. Therefore, each new upload of the package necessarily,
from the Debian perspective, represents a new upstream release.
This means that either there must be a new upstream release each time the
Debian packaging changes, even if there are no effects for other
platforms, or the Debian version of the software package diverges from the
upstream versioning in really unforunate and confusing ways, or you have
to essentially "lie" to the archive about the upstream version to force it
to incorporate a Debian revision and confuse a lot of software and tools.
> But note that it is difficult to draw a line anyway. Among the packages
> I maintain, some show new upstream releases in my radar, which fix
> Windows or Mac OS issues only. Some other project I maintain has a
> friedly version scheme, where the most minor number indicates changed
> relevant to the MinGW port only. All of this is upstream decisions on
> which we can not give more than opinion and guidance.
Certainly. But I think we'd agree that such releases that only affect one
platform are generally unfortunate and can be mildly confusing to users of
the package who don't know whether they need to upgrade or not. Sometimes
they can't be avoided, but where they can, it seems like a good idea to
avoid the confusion.
> The point that I would like to make, is that when there is no upstream
> tarball, whatever the reason, the dpkg native format is a natural choice
> for a Debian package.
I would agree with you more if it weren't for the implications for the
package version, but the implications for the package version are
inextricable from the native format due to the way association of diffs or
Debian tarballs to original source tarballs works or, looking at it from
the opposite direction, the assumptions that are tools and archive
software make about package versions that contain a dash. And the effect
on the package version leads to some noticable problems.
There are good reasons why Debian has a separate package revision number
independent of the upstream version, and this is not something that Debian
package maintainers should discard lightly.
> More in general, for software developped on source hubs, and for which
> the Debian source package is managed as a VCS clone, I see the Debian
> source package itself as nothing more than a vehicle between the VCS and
> the Debian archive of binary packages.
There are very good reasons to favor some sort of 3.0 (VCS) source
format. But using 3.0 (native) as a stand-in for that causes problems
because it breaks various assumptions about the meaning of a native
package.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: