Re: Bug#466550: Pristine source from upstream VCS repository
On Mon, Mar 16 2009, Ben Finney wrote:
> Manoj Srivastava <firstname.lastname@example.org> writes:
>> I would not be against a recommendation in policy to implement
>> direct-from-vcs upstream tarballs to be created vbia get-orig-source,
>> and everyone else just use debian/watch and debian/urepack files.
> Okay, now I'm officially confused. I don't see how the patch  I've
> submitted for this issue does not satisfy what you're saying.
> Ideally, I'd like to see you produce a patch for bug#466550 that
> demonstrates what you're saying, so I can see the difference. I can
> understand if that's too much effort though.
I can see how this discussion could have gotten confusing.
A) Get upstream version from the Debian archive
B) Get a specific version from upstream (perhaps to package, or to
verify the version in the debian archive)
C) Get the latest version from upstream (usually to package it)
In cases B and C above, the upstream distribution can be a
tarball or a VCS.
Let me see if I can capture the current status again. I am
starting with a modified form of Kapil's statement early in the report:
1. Once pkg_ver.orig.tar.gz enters the Debian archive this is considered
the authoritative Debian version from which all the binary Debian
packages will be built (for that version of the package). A
signature/checksum is used (in the upload and the Sources.gz file) so
as to detect any "contamination". apt-get source is enough to get the
latest Debian source from the archive (and wget for older sources)
2. Whenever upstream releases a new version, one needs to create a
pkg_nver.orig.tar.gz for the newer version. In most cases this is merely a
matter of downloading and renaming an upstream tar.gz.
3. If re-packaging of upstream sources was required in order to create
this .orig.tar.gz, then this should be documented in the copyright
file (with some further explication in README.Debian-source
4. If upstream distributes tarballs, the "uscan" and "uupdate" programs
are adequate and there is no significant need for a get-orig-source
5. If the upstream distribution is in the form of a VCS, then uscan does
not cater to it. This seems to be the case where get-orig-source can
fill a need.
There are these three variables that govern the logic:
package in Debian already: Yes/No
Upstream code Mangling Required: Yes/No
Upstream has tarballs: Yes/No
Version to Get: Latest/Current
In tabular/Karnaugh map form (X are the don't care states):
| Already | Version | Has tarballs | Only VCS |
| Packaged | to get | Mangle | Pristine | Mangle | Pristine |
| Yes latest | uscan | uscan | GOS | GOS |
| Yes current | uscan | uscan | GOS | GOS |
| No latest | uscan | uscan | GOS | GOS |
| No current | X | X | X | X |
By logic minimization, the answer is clear :)
While the target was originally designed for cases where we had
to mangle upstream sources, after this discussion and analysis I am
coming to the conclusion that uscan has matured to cover all cases
where upstream distributes a tarball; making the target obsolete. The
places where we do not have an existing solution is if upstream
distributes sources _only_ in a VCS.
Now, your patch states:
+ This target generates the original source archive for
+ the package, such that its contents exactly match the
+ original source archive used to generate the package
+ for Debian.
+ The commands for this target fetch the original source
+ package, corresponding to the Debian package version,
+ from a canonical archive site (for example, via FTP,
+ WWW, or a public VCS repository), do any necessary
rearrangement to turn it into the original source
+ archive file format, and leave it in the current
+ directory. See <ref id="pkg-sourcearchives"> for
+ policy details of the original source archive.
There are some places where I differ:
a) You ask this target only refer to the version in the changelog, and
not the latest version
b) You ask the file is left in the current directory, instead of ../
where uscan leaves it
c) This patch makes the target work for cases where uscan would be
enough -- watch files are useful for DEHS and the PTS and stuff, so
we want to recommend watch files anyway, duplicating uscan in a
target is not desired.
I think that the wording for policy should:
I) Reiterate this target is optional,
II) Suggest that the target be present only when upstream sources were
acquired from a VCS
III) suggest that a variable or option called "GOS_version" be
honored if resent, or else the HEAD of the upstream branch be
used. The contents of the GOS_version would be something relevant to
the VCS being used
IV) suggest that a watch file be used for cases where upstream provides a
tarball, since this is useful in itself
V) suggest that upstream mangling scripts be named debian/urepack, and
if present, should work when invoked as
debian/urepack --version <version> <upstream file name>
Whew. This was longer than I had hoped for.
I hope y'all like it.
Nice guys finish last, but we get to sleep in. Evan Davis
Manoj Srivastava <email@example.com> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C