Re: sourcev3 branch - quilt based source package
On Mon, 17 Mar 2008, Colin Watson wrote:
> > > >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.
Well, that difference is unlikely to go away... I don't feel like adding a
check to forbid binary files in the debian directory. I would like to
allow binary files everywhere but as I explained, it's not a good idea
to do it by default.
And while I could leave the bug open, introducing a new source package
format is already a backward incompatible change and thus I want the new
format to have all the desirable features from the beginning so that we
don't have to wait again one release more to make use of any other desirable
feature. Thus my question.
> 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
> location.
The new source package format tries to have both properties:
- you keep the debian changes separate in the debian/patches/ directory,
but they are auto-applied at unpack time
- you change the sources as you see fit and at build time your changes
are stored as a supplementary patch in debian/patches/
(but this doesn't work for binary files)
> 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.
Indeed. Here's a reworded suggestion:
- debian/source/include-binaries contains a list of paths of binary files
that shall be added to the debian.tar.gz. At unpack time, those
supplementary files will overwrite any pre-existing file in the package
tree.
- a new option is added to dpkg-source to allow automatic generation of the
debian/source/include-binaries file based on the list of files that
could not be added/modified by the generated diff.
I think it's reasonable. I chose to use a "source" sub-directory because I
expect other files related to source-building to appear in the future, in
particular for (non-VCS-based) source packages generated from a VCS (think
debian/source/rules for building the full source package: orig.tar +
debian.tar).
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Reply to: