Hi,
here's an update. team@bpo added to Cc for the part inside <Q> tags.
Cyril Brulebois <kibi@debian.org> (20/06/2011):
> Out of the blue, for a whole new stack, you might need:
> - some x11proto*/libx* updates for the server (example: libxfixes for
> pointer barrier support); maybe for some drivers (example: libxcb*
> for the intel video driver);
> - libdrm, for some drivers, and for mesa;
> - mesa, needed for the server;
As far as building is concerned, I had to backport those source packages:
| libdrm
| libxfont
| mesa
| x11proto-core
| x11proto-xext
| xorg-server
| xorg-sgml-doctools
| xutils-dev
I haven't run-time tested them yet though.
> Some comments follow.
>
> * I would suspect x11proto*/libx* are trivial to backport. libdrm
> shouldn't be too hard either. mesa is a real beast, and is really
> costly, when it comes to CPU eating (and brain damage might occur,
> you've been warned!), probably one of the biggest task.
Done.
As far as libdrm is concerned, see the thread about libdrm vs. plymouth;
upgrading libdrm and the server at the same time would allow us to
backport a newer version of the nouveau driver, which would have the net
effect of working with squeeze-backports' kernel (the version in squeeze
just works with squeeze's kernel and kernels below 2.6.34-rc1).
> * Once libraries in place, the server should be quite easy to backport.
> But some drivers might have been dropped in the meanwhile, so meta
> packages might need be adjusted, so that they are still installable;
> that's probably going to be a boring part of the job.
>
> * Drivers should also be an easy task. But there are 40-50 of them. So,
> again, boring. :/
<Q>
I'm wondering whether the following approach would look reasonable from
a backports policy point of view:
- backport “common”[1] drivers to squeeze-backports, built against
squeeze-backports' server,
- do not backport non-“common” (all other) drivers to squeeze-backports.
1. Those listed on this page:
http://pkg-xorg.alioth.debian.org/reference/squeeze-backports.html
That would have the following effects:
- meta packages (xserver-xorg-{input,video}-all) would need no updates;
- installing common drivers along with the new graphics stack would
require removing non-common drivers (which would be built against,
and depending on the old server), along with the aforementioned
metapackages;
In other words: only people using common drivers would be able to
upgrade their graphics stack. Others could still request a backport of a
specific driver if they need/want it; and then we would add drivers on a
case by case basis, which is far better than doing a bulk upload of 50
drivers.
I realize being unavailable to keep all packages co-installable isn't
ideal, but I can't think of a better way. (Also, it should be noted that
the lists of drivers available in squeeze and in sid aren't exactly the
same anyway, so there's no way to guarantee each driver can be
upgraded.)
Of course, detailed instructions would be published, so that people can
determine whether it's appropriate to perform this upgrade, and how to
give the package manager a hint if it isn't good enough at its job.
[I only performed a test through dpkg -P/dpkg -i so far.]
</Q>
> * Finally, multiarch is on its way in unstable, and stable has no
> multiarch support. So I would suspect one would have to revert the
> multiarch changes. That would also mean taking extra care of versions
> in Breaks, Conflicts, etc. (see the mesa mess these days[1]). That's
> probably a difficult task (as in: need extra care).
>
> 1. http://blog.mraw.org/2011/06/18/mesa_a_disturbance_in_the_Force/
Disabling it is quite easy. As for mesa vs. server (partial upgrades), I
think it should be possible to handle all stable / squeeze-backports /
{testing,sid} cases by providing both “mesa-no-multiarch” and
“server-no-multiarch” in the squeeze-backports packages, so that the
multiarch-enabled packages (in testing/sid) can Break them, in addition
to the current versions. This will ensure partial upgrades from
squeeze-backports to testing/sid don't break.
Thoughts?
Mraw,
KiBi.
Attachment:
signature.asc
Description: Digital signature