[ubuntu-x] Testing enablement mechanics (or are there better solutions?)

[Maarten Lankhorst]

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.

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.

Some more digging even finds a versioned depends on xserver-xorg-core, so renaming won't work. virtualbox-guest-x11 depends on Xorg >= 7.

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.

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

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