On Wed, 2012-05-16 at 14:25 +0200, Maarten Lankhorst wrote: > Hey, > > Doing some more testing I haven't found a good way to do this yet. I > tried doing things similar to the way the xorg rename script is going > to work, and I just can't get a good way of automatically forcing a > upgrade. The official way of upgrading to a renamed package is to > provide a 'transitional' package that's empty and just depends on the > new name, and it would the only way to make this work without breaking > everything. However in this case I don't see an advantage to just > using exactly the same names.
The advantage is that we can have multiple stacks in the archive at once - Q, R, S, and T. The plan was to support each of those stacks in 12.04 for as long as the release they're based on is supported. > > For example there are some non-trivial depends on x11proto packages: > $ apt-cache rdepends x11proto.* > The most important one being x11proto-core-dev. However in the generic > case it will stay backwards compatible, so they will all have to be > reviewed to make sure existing code won't break. Those should be safe, but they will indeed need review. > > Some more digging even finds a versioned depends on xserver-xorg-core, > so renaming won't work. virtualbox-guest-x11 depends on Xorg >= 7. That sounds like virtualbox-guest-x11 should also be renamed. After all, it is a DDX; it'll need to be backported/rebuilt against the new stack. > > Similarly, some input and video drivers have dependencies: > gpointing-device-settings depends on input-synaptics, open-vm-toolbox > on vmmouse, xserver-xorg-input-wacom has ubuntustudio-graphics and > kde-config-tablet, bunch of others too. Stupid packages ☺. Are any of these dependencies versioned? Can they be satisfied by the renamed packages Provide: ing their un-renamed package? Alternatively, if it's a small set of packages we could SRU them to remove the dependency. > More fun is that if you try to install the unrenamed package, your > package manager will solve the conflict by removing the enablement > package and downgrade to it. This seems like a recipe for disaster and > not really suitable as a working solution. As long as users need to *deliberately* install the un-renamed package I think this is ok. We have a limited ability to prevent people from shooting themselves in their feet. This was, however, the sort of thing that I was concerned about in the session. > Also the enablement package won't automatically upgrade to newer > versions, so you will stay on lts-q for the rest of the release unless > you manually force an upgrade. We should be able to handle that when the lts-q stack drops out of support by uploading a new lts-q metapackage that depends on lts-t (or whatever we decided the upgrade path was). Obviously this needs testing, though! > > ppa would be fine for testing, but I don't think it's set up to have > millions of computers pull updates from it, and companies want to have > their own mirroring set up to save unnecessary bandwidth. Would it > really be impossible to poke the launchpad devs some more for this, > since it seems to be the only clean solution to have either only the > stable stack in main and an updated stack in backports (which can be > held back on a large scale with pinning as needed) or the use of > multiple pockets. > > I don't believe we should go with the rename route at this point, > until we figure out a way to do it cleanly and automatically. > > I created 2 test repos, enable the normal one and the lts-q one for > testing, lts-r is unused atm: > https://launchpad.net/~mlankhorst > > You can force installing dummy-enablement to the original version, and > simulate what would happen if you upgrade to the current version, and > see it's going to be held back. Furthermore dummy-dev will fail to > install after upgrading and won't suggest dummy-dev-lts-q or anything. > > ~Maarten >
signature.asc
Description: This is a digitally signed message part
-- Ubuntu-x mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-x
