Re: sourcev3 branch - quilt based source package
On Sun, 16 Mar 2008, Colin Watson wrote:
> In article <[🔎] 20080315142433.GA6789@ouaza.com>, Raphael Hertzog wrote:
> >I pushed the last (functional) changes that I wanted to have in the
> >sourcev3 branch: a module handling a format named "3.0 (quilt)" which
> >is wig&pen based. I made the choice to directly use quilt if available
> >so that after extraction, one can continue to use quilt without finding a
> >way to recreate the ".pc" directory. Also the source generation is smart
> >enough to ignore this directory.
>
> With regard to the sourcev3 branch, could you please also apply the
> appended patch for 3.0 (bzr) support? See
> http://lists.debian.org/debian-dpkg/2007/10/msg00026.html for the
> initial implementation of this; I've brought it up to date with the
> changes to the git implementation.
I have no objection to integrate it as well. But I will mark both
VCS-based format as experimental in the documentation anyway.
> (The thread was very long with many digressions, but I don't think there
> were substantive objections to including 3.0 (bzr) support there. The
> only major concern I remember being raised was that of an equivalent to
> git's shallow clones, which I'm pretty sure is on bzr's roadmap; in any
> case this only really makes much of a difference for large and old
> packages, and there are enough cases of tolerably-sized bzr branches
> that it seems worthwhile despite that.)
And the current git implementation doesn't create a shallow clone anyway,
it's still a TODO in the code IIRC.
> >- copy upstream tarballs in the extraction directory for
> > all formats (and take it the relevant part out of the Format: 1.0 code).
>
> Am I confused? I admit that I haven't really looked at 3.0 (quilt), but
> I thought that at least 3.0 (git) wasn't going to have a separate
> upstream tarball.
Yes, "3.0 (git)" doesn't use an upstream tarball but "3.0 (quilt)"
does. I should have said "for all formats where it's relevant". :-)
> >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=4588
> >Support addition of binary files. Now that the debian directory
> >is stored in a separate tarball, it's possible to add binary files
> >in the debian directory but it's not possible to add them directly in some
> >upstream directory, they have to be moved in place at build time if
> >needed. Is that enough to consider this bug solved?
>
> Still inconvenient, just not quite so inconvenient as before ...
What would you suggest instead?
On alternative that I tought of is to create a
<source>_<version>.overlay.tar.gz containing (binary) files to be dropped
on top of the uptream sources. It shouldn't be too hard to do, but I
wonder if it won't create more problems than it will solve (building
source package with unclean source tree would lead to spurious overlay
tarballs when it used to fail up to now).
Or we could decide to include those in the debian.tar.gz directly (but it
means we're even less likely to notice the addition of spurious binary
files).
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Reply to: