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

Re: Reforming 'orig.tar.gz' with included tar-ball.



Mats Erik Andersson <mats.andersson@gisladisker.se> writes:

> Hello all mentors,
>
> I am in the process of fulfilling an ITA filed on an orphaned package.
> However, I now experience a desire to begin patching the upstream
> source for compiling errors and spelling errors in the manual page.
>
> To my dismay the previous maintainer chose to let the 'orig.tar.gz'-file
> contain the packaged and compressed upstream tar archive. My personal
> taste is to abondon this practice, if for no other reason to simplify
> the rules-file.
>
> Is there some reverence that should prevent me from taking the step
> of letting a new 'orig.tar.gz' be a byte-for-byte copy of the upstream
> source archive? I will make the new package conform to "3.0 (quilt)".
>
> -- 
> Mats Erik Andersson, fil. dr

I only know of one reason to have a upstream.tar file inside the
orig.tar (but there might be more, not important here). It makes it
simpler to build multiple flavours of a source. E.g.:

- with different configure arguments when out-of-tree builds aren't
  supported
- with different patches applied

Unpacking the upstream.tar to build-<flavour> and deleting that in clean
makes for a simple rules file. Also helps if upstreams build system
doesn't have a working clean target.


But now we have the 3.0 (quilt) format that supports multiple upstream
tarballs. A little trick you can do there is to have an empty
package_1.2.orig.tar.gz and the actual upstream source as
package_1.2.orig-upstream.tar.gz/bz2. The source gets then automatically
unpacked into a subdir (upsream in this example) and you can copy that
to build-<flavour>. As a bonus you can use the 3.0 (quilt)
debian/patches feature on the upstream dir and only need your own patch
system for the per flavour patches (if you have any).

So even for the case where I think tar-in-tar was better the 3.0 (quilt)
format solves that. Having the upstream source unpacked and using
pristine-tar saves a lot of space in a version conrol system and makes
tracking changes in upstream a lot simpler imho.

MfG
        Goswin


Reply to: