Re: dpkg patch
Joey Hess writes ("Re: dpkg patch"):
> 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?
Many packages nowadays are maintained by teams sharing a revision
control system. When this happens many others who work with the
package end up using the same RCS to prepare NMUs, local versions,
etc.
So I think in these cases the fact that a particular RCS is being used
is a fact about the package and not about the person doing the work.
It should be stored with the package.
> 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.)
This kind of question obviously needs to be thought about.
Someone packaging locally might well want to include the RCS files
even if the maintainers choose not to. So having an option to
override that makes some sense.
> 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.
Yes.
> 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.
I agree with this, I think. That's not to say that Ubuntu's ought to
be identical. For example, Ubuntu's dpkg-buildpackage has a patch to
check that the Maintainer field has been adjusted properly according
to the Ubuntu policy - but of course that policy which was instituted
at Debian's request.
I think what's important is any changes to the package formats and
metadata ought to be implemented coherently so that there is only one
set of standards for what a particular package's control information
means. So changes of this kind should really be discussed and decided
with Debian's involvement.
Ian.
(no longer employed by Canonical, FAOD)
Reply to: