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

Re: Ownership issue when repacking source in get-orig-source target



Le Fri, Jan 13, 2012 at 01:58:50PM -0800, Russ Allbery a écrit :
> 
> However you generate the .orig.tar.gz file, you can then manage it with
> pristine-tar, at least if you're using a VCS that pristine-tar supports.
> The process when you repack upstream is really the same as when you just
> download upstream from pristine-tar's perspective.

Hi,

the problem we have in the Debian Med team is that we do not want to impose the
use of git-buildpackage to occasional uploaders, as Git is not the most chosen
VCS (I hope it will be some day).  We are looking for a workflow that lets them
do everything with a clone of the master branch only.

When a package is already in Debian, apt-get source gets the pristine upstream
source.  After all, what defines what is pristine is the Debian archive.

The problem comes when the upstream sources are repacked.  With our Subversion
workflow, the MD5 sum of the ‘pristine’ archive is fixed at upload time.  But
with Git it is fixed when we import the new upstream revision in the
repository.

Therefore, if a sponsor uploads such a package, he may introduce a MD5 mismatch
between the pristine-tar branch and the Debian archive.  Or he has to learn
to use git-buildpackage, which means less sponsoring, at least in the short term.

If it is lost in advance to create stable repacked sources, perhaps the simplest
is to correct the pristine-tar a posteriori when such MD5 mismatches happen…

Another workaround would be to have debcheckout track all the branches by
default; requested in http://bugs.debian.org/625940.  But this does not
completely solve the problem, as when working on the master branch, ‘git pull’
will not automatically fast-forward the pristine-tar branch.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

… by the way, how about accepting the 3.0 (git) format in our archive ?


Reply to: