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

Re: sourcev3 branch - quilt based source package

On Sun, Mar 16, 2008 at 11:42:20AM +0100, Raphael Hertzog wrote:
> On Sun, 16 Mar 2008, Colin Watson wrote:
> > 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.

No problem. Thanks for the commit.

> > >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?

I'm not sure I have a suggestion in the context of 3.0 source packages
at this time, but, at the risk of stating the obvious, it's OK to leave
bugs open when they aren't yet really fixed. I think it would be very
confusing (to those without substantial experience of dpkg-source's
code) if binary files were allowed in some places but not others.

> 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).

Firstly, the separation between "upstream" and "Debian" parts of the
source tree is rather artificial to me, and only really makes sense if
you're used to keeping all your changes to the upstream source in the
debian/ directory. I thought one of the points of the new source package
format was to obsolete that practice; you should once again be able to
make your changes wherever they make most sense and have the toolchain
sort it out for you. The distinction between "upstream" and "Debian"
should depend on who made the changes, not be an artifact of filesystem

Secondly, I agree with you that it is important to avoid accidental
spurious binary files; it would be very easy to produce GPL violations
by accident if dpkg-source allowed these by default, so I think it is
correct for them to be disallowed by default. Therefore the problem is
simply one of configuration: dpkg-source should offer a way to override
its default for specific, maintainer-chosen paths within the source
package. Perhaps something like a newline-separated list in
debian/dpkg-binaries would do the job.

Colin Watson                                       [cjwatson@debian.org]

Reply to: