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.
signature.asc
Description: This is a digitally signed message part