Charles Plessy <ple...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrbws23y....@windlord.stanford.edu
