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

Re: Bug#692000: ITP: liblbfgs -- L-BFGS solver for dense nonlinear optimization problems



> On Sun, 11 Nov 2012 22:57:41 +0100
> Andreas Tille <tille@debian.org> wrote:
>
> On Sun, Nov 11, 2012 at 01:29:17PM -0800, Dima Kogan wrote:
> > >    dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at ../libdogleg_0.08.orig.tar.{bz2,gz,lzma,xz}
> > > 
> > > Any reason to not use pristine-tar?
> > 
> > I can use pristine-tar here, but I'm not completely clear on why it is useful.
> > The upstream source comes from a tag in a git repo. This tag fully describes the
> > sources. One could make a tarball from this tag (this is what pristine-tar would
> > do), but why would this be a useful thing to do? Tell me if having a
> > pristine-tar branch is desirable, and I'll set it up.
> 
> Pristine-tar ensures a tarball with identical MD5 sum which is pretty
> important if different people try to upload different package versions
> of the same upstream version.  In case somebody else than me who did the
> initial upload with MD5sum abc tries to create a Debian package '*-2'
> and does not download the tarball via dpkg-source he will end up with a
> different upstream tarball (not byte different when unpackaging but with
> different md5sum).  This will result in a rejection from ftpmaster.

I'm not sure this is entirely correct. The contents of the upload are dictated
by the .changes file, which is constructed by dpkg-genchanges. dpkg-genchanges
has logic in it to only include the .orig.tar.gz when a new upstream version is
being built (based on debian/changelog). Thus if somebody builds a *-2 package
and debian/changelog says that a *-1 exists, dpkg-genchanges won't ship the
*.orig.tar.gz at all, since one presumably exists on the master server already.
I guess I don't like the redundant data that the pristine-tar archive contains,
and would prefer not to use it without a compelling reason.

> > Also, git-buildpackage can create a tag in the repo to identify particular
> > package releases. One can make it with 'git-buildpackage --git-tag'. I'll do
> > this now for liblbfgs.
> 
> I know this however, in the case of an initial upload I tend to do the
> tagging manually once the package was really accepted.

OK. I jumped the gun with my tag then. Hopefully the package will get in.

Thanks again

dima


Reply to: