Re: how do I create orig.tar.gz archive ?
>>"Chris" == Chris Waters <firstname.lastname@example.org> writes:
Chris> Marcelo E. Magallon wrote:
>> Peter is correct. Just a small note: it is VERY important that the
>> .orig.tar.gz IS the original tar.gz (the name doesn't matter);
Chris> Hmm, I note that the cvs-buildpackage package creates a new
Chris> .orig.tar.gz file. If it were *that* important, surely this
Chris> standard debian tool would have a way to deal with the issue?
I was was going to give you the courtesy of believing that
you would have read the documentaion that came with the package, but
that would have done the discourtesy of realizing that maybe the
documentation was, umm, unlcear, to you, so I am reverting to the
stance that you probably did not read it.
cvs-buildpackage is compatible with the use of pristine
source. It does not, in the documentation, imply that you should
not use pristine source. Yes, it does recreate the sources from CVS
if it has to, but that is an extention, not the norm.
The current (informal) policy is that pristine upstream
sources are preferred, but not mandatory (since in certain cases, as
you point out, it is impossible to use pristine sources).
Chris> IMO, the advantages of having pristine upstream tarballs are
Chris> *far* outweighed by the advantages of CVS.
What on earth make you think it is an either or situation?
Chris> If it's really *that* important to have pristine
Chris> .orig.tar.gz's, perhaps a bug should be filed against
Just make my day. Are you generally this eager to fire off bug
reports? Have you ever considered that reading documentation is a
CVS-BUILDPACKAGE(1) Debian GNU/Linux manual CVS-BUILDPACKAGE(1)
Root of the original sources archive. We expect to
find the <package name>_<version>.orig.tar.gz file
under <root directory>/package name>/ unless the
work directory has been set, or we want to export
the original sources from the vendor branch of the
From the HOWTO file: It mentions the upstream sources as a
orig.tar.gz file when importing:
3. Prepare to use CVS
With the addition of cvs-inject, this process is essentially just
one line. Assuming you have created a set of files for upload,
including the orig.tar.gz, the .dsc. and the diff.gz file, just
$ cvs-inject <path to .dsc file>
And here is how we update/upgrade the sources:
7. Updating a module with the import command
When a new release of the source arrives, you import it into the
repository with the same `import' command that you used to set up
the repository in the first place. The only difference is that you
specify a different release tag this time, and a different message.
This is easier now with the cvs-upgrade program. Put the
orig.tar.gz file in the working directory for your site (typically
/usr/local/src/Packages/<Package name>). The upstream sources
should be put in
<Work directory>/<Package name>_<upstream version>.orig.tar.gz
$ cvs-upgrade <Package Name> <upstream Version>
This shall unpack the original sources, and import them on the
vendor branch. Since the upgrade may involve conflicts, this is not
fully automated; cvs-upgrade stops to let you handle any conflicts,
reminding you resolve conflicts, check things in, and tag the new
Is it so hard to understand?
Chris> Note that 1) in many cases, using the pristine upstream tarballs is
Chris> either impossible or undesirable,
Chris> and 2) you already have to trust the developer to deliver a
Chris> reliable *binary*, why get all paranoid about the sources? It
Chris> doesn't take that long to do a diff -r against the source
Chris> trees if you're really curious.
You have to be kidding. Espescially for packages where the
upstream sources have detatched signatures, you really think we
should blow that off?
If this is a service economy, why is the service so bad?
Manoj Srivastava <email@example.com> <http://www.golden-gryphon.com/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E