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

Updating debian/control at build time



Hi,

I have a policy question: I'm working on various PostgreSQL extension
packages that all build several postgresql-foo-$version packages
(where $version is 8.4 and 9.0 atm). We have infrastructure for that
in postgresql-server-dev-all called pg_buildext, but that wasn't used
at all until recently. I'm working with the author to fix that :)

In /usr/share/postgresql-common/pgxs_debian_control.mk, there is a
debian/rules snippet that updates debian/control from
debian/control.in. For every version, all packages containing
"PGVERSION" in their name are instantiated; the source stanza and
non-"PGVERSION" packages are not modified.

The list of versions is the intersection of debian/pgversions and what
/usr/share/postgresql-common/supported-versions outputs.

#
# produce a debian/control file from a debian/control.in
#
# In debian/rules, include /usr/share/postgresql-common/pgxs_debian_control.mk
# build: debian/control
#
# Author: Dimitri Fontaine <dfontaine@hi-media.com>
#
debian/control: debian/control.in debian/pgversions
	grep-dctrl -vP PGVERSION $< > $@

	for v in `pg_buildext supported-versions $(SRCDIR)`; \
        do                                         \
		grep -q "^$$v" debian/pgversions   \
		&& grep-dctrl -P PGVERSION $<      \
		| sed -e "s:PGVERSION:$$v:" >> $@; \
	done

(I think "clean: debian/control" is the better place to put the
dependency, but this doesn't matter for the question.)

What happens is:
 * Once supported-versions drops versions, packages will disappear
   from debian/control
 * If debian/pgversion lists versions not yet supported, these
   packages will appear as soon supported-versions add them.

As the set of possible packages is under maintainer control via
debian/pgversion, I think this works as intended, namely making
adding/removing PG versions binnum'able. As this might cause surprises
for buildds "suddenly" building a different set of packages, it might
not be desirable for others.

What do the release people think about that?

The alternative would be to make the control update a manual step.

Christoph

(PS: #311724 is similar, but a different section in debian/control.)
-- 
cb@df7cb.de | http://www.df7cb.de/

Attachment: signature.asc
Description: Digital signature


Reply to: