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

Upcoming package updates

Hi folks,

xsfbs was nice once upon a time, since it made it possible to handle
several repetitive tasks:
 - patching/unpatching.
 - computing substitution variables.
 - generating maintainer scripts using macros.

Now, during the last year, I've noticed the following:
 - a simple mistake in xsfbs (e.g. the dependency issue we have when
   patching, leading to unnecessary rebuilds) has to be fixed once but
   merged into each package. That's not really nice. And quilt makes
   it easy to get patches applied/unapplied today, either through
   quilt.mk or through dh --with quilt.
 - when updating the method used to compute substitution variables,
   one has to merge it into all drivers, which is also not
   nice. Shipping a script in xserver-xorg-dev (and consequently
   bumping the build-dep on it) and calling it from drivers' rules
   file is sufficient. Code duplication goes away. Hence the proposed
   dh_xsf_substvars proposed on [1]. If that script needs tweaking,
   it'll probably happen with a new major version, meaning we'd have
   to bump the build-dep on xserver-xorg-dev anyway. Or we could just
   handle this through binNMUs.
 - a really small number of drivers (didn't check other packages yet)
   use maintainer scripts. We could probably replace xsfbs macros with
   dpkg-maintscript-helper. Or keep xsfbs merged into those for a

Also, trying to lower the packaging noise, I'm quite tempted to just
use dh, so that only non-trivial bits appear in debian/rules, see
libxkbcommon's rules file for example [2].

It would mostly boils down to something based on:
| #!/usr/bin/make -f
| %:
| 	dh $@ --with autoreconf,quilt --builddirectory=build/

I've pushed an update to -evdev to a personal repository on alioth
[3,4] to show another example.

If we want to refine it a little bit more, we could also ship an xsf
sequence in xserver-xorg-dev. At the moment, it would just ensure
dh_xsf_substvars gets called before dh_gencontrol. But it could also
be used to run some other dh_xsf_* commands at some other places,
should we ever need more xsf-specific stuff. The call would then
| %:
| 	dh $@ --with autoreconf,quilt,xsf --builddirectory=build/

Finally, I'm not sure we need to build out-of-tree. It's easy to
clean, but I guess we could just fix clean targets if they break. As
far as auto*-related files, they are taken care of by dh-autoreconf,
so the debian clean target does its job properly. So I guess we could
get rid of --builddirectory=build/ as well. Of course, building OOT is
the way to go for the small amount of packages with several flavours.

 1. http://pkg-xorg.alioth.debian.org/reference/dependencies.html
 2. http://git.debian.org/?p=pkg-xorg/lib/libxkbcommon.git;a=blob;f=debian/rules
 3. http://git.debian.org/?p=users/kibi/pkg-xorg/xserver-xorg-input-evdev.git
 4. http://git.debian.org/?p=users/kibi/pkg-xorg/xserver-xorg-input-evdev.git;a=blob;f=debian/rules;hb=debian-experimental

Any drawback/objection for any of this? Summarizing:
 - kiss xsfbs good bye.
 - new dh_xsf_substvars in xserver-xorg-dev.
 - probable move to dpkg-maintscript-helper where needed.
 - switch to dh.
 - ship a dh sequence.
 - stop building OOT for single-flavoured packages.

I might wait for the new upstream release (candidate?) of the server
to upload a dh_xsf_substvars-enabled xserver-xorg-dev package, so that
we can bump the build-dep in drivers to a new upstream release, rather
than having to remember the debian-specific revision in which this
command got introduced. (Preparing drivers in git should keep me busy


Attachment: signature.asc
Description: Digital signature

Reply to: