[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: how do I create orig.tar.gz archive ?



Hi,
>>"Chris" == Chris Waters <xtifr@dsp.net> 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
 Chris> cvs-buildpackage?

	Just make my day. Are you generally this eager to fire off bug
 reports?  Have you ever considered that reading documentation is a
 good thing? 

______________________________________________________________________
CVS-BUILDPACKAGE(1)  Debian GNU/Linux manual  CVS-BUILDPACKAGE(1)
       -R<root directory>
              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
              CVS tree.
______________________________________________________________________

	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
   say: 

        $ 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
   version. 
======================================================================

	Is it so hard to understand?

 Chris> Note that 1) in many cases, using the pristine upstream tarballs is
 Chris> either impossible or undesirable,

	Yes. 

 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?

	manoj
-- 
 If this is a service economy, why is the service so bad?
Manoj Srivastava     <srivasta@acm.org>    <http://www.golden-gryphon.com/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


Reply to: