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

Re: Backporting a whole X stack



   Hi,

* Cyril Brulebois <kibi@debian.org> [2011-06-27 01:50:20 CEST]:
> here's an update. team@bpo added to Cc for the part inside <Q> tags.

 Thanks for the updated plan.

> 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.

 Even if this can be read as being implied, I understand that you plan
to test them. Thanks in advance for that!

> 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;

 Sounds very reasonable to me. Thanks a lot for outlining it. One
question that sits in the back of my head, maybe I overlooked it, what's
with the debhelper helper scripts that were originally suggested to put
in one of the packages? They will flow in through xserver-xorg-dev which
is built from xorg-server source package, right?

> >  * 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.

 *Extremely* reasonable and thanks a lot for thinking about these cases,
too. Thanks a lot!

 I really can only hope that your thoughtful approach here can be seen
as encouraging example to others.

 Enjoy!
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los      |
Fühlst du dich hilflos, geh raus und hilf, los    | Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los    |


Reply to: