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

Upstream tar.gz in orig file à la dbs (was Re: dpatch & upstream source)



On 2 November 2005 10:42, Justin Pryzby wrote:

[Changed to a more suitable subject]

> On Wed, Nov 02, 2005 at 10:08:13AM -0500, Fran?ois-Denis Gonthier wrote:
> > On 2 November 2005 09:13, Junichi Uekawa wrote:
> > > Hi,
> > >
> > > > I'm working on some big changes for the new upstream of the erlang
> > > > packages. The biggest change is that the package is now fully using
> > > > dpatch, *but*, basing myself on some other package I've seen
> > > > (coreutils for example), I've put the compressed upstream right in
> > > > the package.  It is extracted using a dpatch scriptlet.
> > > >
> > > > Is it okay to do that, for one thing?
> > >
> > > Out of interest, I would be interested in the advantages of having a
> > > tarball like that.
> >
> > I'm no expert, but in my case it limits the changes done to the upstream
> > source to what is done with the patches.  Erlang build system leaves a
> > bit of changes behind after the build and that went right into the .diff.
> >  My cleaning rules used to be ugly and even that didn't keep unwanted
> > changes from slipping in the .diff
>
> Any reason to use a .tar.gz or .tar.bz2 instead of an .ar archive?
> Seems that would be more efficicient with CPU.

This would probably be repackaging... The question is if I'm not already 
repackaging by putting the upstream tar.gz into the orig file.

> Also, how does this work WRT pristine source requirements?  I notice
> that coreutils embedded upstream tarball is pristine, but of course
> the .orig is not.

That's the kind of question I'm looking answers for.  In the developer manual, 
it is clearly said that the .orig.tar.gz should be a "byte-for-byte identical 
to a tarball officially distributed by the upstream author."

... but, dbs does it.  coreutils is just an example.  I've seen some other 
package doing that.  There are probably many of them but I don't download 
source package very often.

> --
> Clear skies,
> Justin

Attachment: pgpt9mVLYvElh.pgp
Description: PGP signature


Reply to: