Bug#555446: uploaders.mk: regenerates debian/control in clean target

Vagrant Cascadian vagrant at freegeek.org
Tue Nov 10 01:51:47 UTC 2009


On Mon, Nov 09, 2009 at 11:38:06PM +0100, Josselin Mouette wrote:
> Le lundi 09 novembre 2009 à 10:26 -0800, Vagrant Cascadian a écrit : 
> > while attempting to backport a package (sabayon) that uses uploaders.mk, and
> > editing the build-deps in debian/control, i was surprised to find that my
> > changes to the build-deps were obliterated in the clean target.
> > 
> > it seems that gnome-pkg-tools, and many other packages that make use of
> > uploaders.mk in debian/rules do the same.
> 
> Indeed, and it’s the only sane way to manage a large number of packages
> with a large number of uploaders.

it's a way to accomplish a challenging task, yes.
 
> > there's no debian/README.source documenting that you actually need to edit
> > debian/control.in instead of the usual convention of editing debian/control to
> > make changes.
> 
> There’s a README.Debian. Do you expect its contents to be copypasta’ed
> to all GNOME source packages? That would be plain stupid.

no, i don't expect that at all.

a short reference in debian/README.source would seem useful to me. perhaps
consider something like:

  do not edit debian/control directly, as it is regenerated automatically.
  please see /usr/share/doc/gnome-pkg-tools/README.Debian.gz for further
  explanation.

then the documentation can reside in a single place, and only require
infrequent changes to the individual README.source files.

> > there are several reasons mentioned in the ftpmaster reject FAQ why it's
> > generally a bad idea to edit debian/control during the course of a build,
> > namely that it could change the build-dependencies from one run to another.
> > 
> > while the build-dependencies are probably not going to change in most cases, it
> > seems possible that a security or NMU upload might be prone to error.
> 
> The build-dependencies will certainly not change because of that.

attempting to change the build dependencies was precisely how i discovered the
issue, so i find that assertion hard to understand.

a simple binary NMU will not cause such problems with build-deps, although the
uploaders field may still change between given builds, and might be
inconsistant across architectures... that aspect seems relatively minor to me,
though.

what seems important, at least to me, is that undocumented unexpected behavior
will very plausibly cause someone frustration and unnecessary wasted time.

hopefully that can at least be taken into consideration, and find way that
isn't overly burdensome on the maintainers who do the bulk of the work.

thanks!

live well,
  vagrant





More information about the pkg-gnome-maintainers mailing list