Hi, * Cyril Brulebois <[email protected]> [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 | -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
