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

[Christopher James Halse Rogers]

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
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-x/attachments/20120518/09ab7ec5/attachment.pgp>