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

Re: Upcoming package updates

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

Reply to: