Re: git-buildpackage and tarballs
Le Sat, Oct 22, 2011 at 07:08:45PM -0700, Russ Allbery a écrit :
>
> The same issue as with a tarball applies, though: unless the intention is
> to tag a new upstream release every single time a new version of the
> Debian package is uploaded (or unless the upstream doesn't even tag
> releases, but I would strongly recommend against that), the native format
> isn't appropriate.
>
> Basically, using the native format enforces release practices that are
> mildly unfriendly to non-Debian consumers of the software. It means there
> will be a new full upstream release even if the only changes are
> Debian-specific packaging changes and hence of no interest to anyone else.
> This isn't necessarily that big of a deal, but it's awkward, and once one
> invests in the one-time tool configuration effort required to separate the
> two release flows, generally unnecessary.
Hi Russ,
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 agree with you on the first, and as you noted, it is equally true for all
dpkg source formats used. There is no need to trigger update on other systems
when the changes only affect Debian. 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.
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. In particular, for the native format as for the other formats, there
is no promise that the tarball is the one distributed upstream (I am aware of
Develpers Reference's §6.7.8.1.2, but I do not think it is widely followed, nor
relied on by our infrastructure). 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. (In that sense,
the VCS-* field is the most relevant information about source, and the source
package is not a preferred form for modification, but that is another story).
Have a nice Sunday,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Reply to: