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 while. 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 become: | %: | 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. References: 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 already.) KiBi.
Attachment:
signature.asc
Description: Digital signature