Re: dpkg patch
hi Joey
Thanks for cc:ing me on the reply.
On Fri, 2007-11-02 at 17:55 -0400, Joey Hess wrote:
> dpkg-source options -I and -i already solve the problem of excluding
> files from a tarball and diff. That works well for excluding revision
> control system files. Why would you want to put this information about
> the revision control system you're using into the source package?
The reason for these files is obviously to avoid the need to remember to
type -I or -i every time. I'm interested in the following packaging
workflow for packages that are maintained in git and not released as
tarballs:
0) make a local 'debian' branch containing the packaging files
to do a release:
1) merge upstream git to my local 'debian' branch
2) dch, etc
3) debuild
I am not interested in forgetting to type -I.git and uploading a tar
file full of .git/ files.
btw: I think, used properly for this use case, the tarignore file would
list itself. This way it isn't included as part of the source package
and nobody has to suffer. It serves it purpose by removing .git -- and
goes away along with it.
> I suppose that diffignore could be used as an alternative to a proper
> debian/rules clean target, if the build modifies some files and it's
> too much bother to undo the modifications in clean. But is there really
> a benefit from making it easier to write clean rules that don't fully
> clean the build tree? What if the someone later needs to modify the
> diffignored files to fix an issue in the package? They then build a
> source package, and it silently fails to include their modifications!
I only implemented diffignore after Scott looked at my first patch and
told me that it seemed strange to have tarignore without diffignore. :)
In any case, I'm not particularly interested in the use case you mention
because, as you mention, it's pretty ugly...
> Also, as implemented, dpkg-source -i overules the diffignore file. So if
> you put a file in diffignore, everyone who builds the package has to be
> very careful not to use dpkg-source -i. Inconsistently, dpkg-source -I
> doesn't override the tarignore file. (Nor does an empty tarignore file
> lead to the default -I behavior, like an empty diffignore does.)
If I were to modify this I guess I would make the presence of -I on the
commandline ignore the tarignore file. Seems sane.
> Finally, the regexps in debian/diffignore can be used to cause
> dpkg-source to run arbitrary code (embedded in the regexp via (?{ code })
> when building a source package. This is not as dire as if it ran arbitrary
> code when unpacking a source package, but it is still a new security issue,
> and I think dpkg-source should be safe to use to build source packages
> without worrying about code injection.
1) In almost any sane situation, building the source package involves
running the clean rule first.
2) Someone with slightly more perl-fu than myself could surely write
some regexp to detect exploit attempts.
> (BTW, your YY_TEXTPOINTER change seems to have nothing to do with
> rest of the patch.)
It is true! Not sure why that showed up but I guess I'd probably merge
it? *shrug* :)
> > Pending further review this will be in Ubuntu's dpkg soon.
>
> I have the same opinion of unnecessarily diverging ubuntu and debian's
> dpkg as I have of diverging debhelper. It will come back to haunt all of
> us. If you think it won't, just look at the gawdawful mess rpm has been
> in over the past few years, with each vendor maintaining slightly
> incompatible versions.
Can't speak to this, but I like this functionality and I think that
Debian might like it too. Having at a tarignore that you can put in
your packaging branch in git that nukes itself is an insanely handy
thing. I don't really care about diffignore since I don't use git to
maintain packages with orig tarballs (and can't imagine how this might
work...).
An obvious alternative to this whole patch is just to ignore .git (and
friends) by default. I'm not convinced that this is a particularly good
alternative.
Thanks for the detailed reply.
Cheers
Reply to: