On Wed, 2011-02-02 at 06:47 +0100, Cyril Brulebois wrote: > 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]. > I, too, like the way dh makes the interesting parts of the packaging obvious by omitting all the non-interesting bits. Also, unlike CDBS, it's quite straightforward to make the interesting bits happen :). > 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/ > I'm a fan of automating common tasks. I think this might also be helpful in getting the small, but annoying, number of drivers that aren't maintained by the XSF to properly declare dependencies. > 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. > I think that out-of-tree interacts poorly with ccache, but (a) that could be PEBKAC, and (b) for the packages where ccache is interesting we need to do out-of-tree builds anyway for the multiple flavours. I'm therefore of no strong opinion on out-of-tree. > > 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: This is a digitally signed message part