Re: Stable update proposed for ganeti (fixing #528618)

[Iustin Pop <iusty@k1024.org>]

On Tue, Aug 04, 2009 at 05:01:39PM +0100, Adam D. Barratt wrote:
> Iustin Pop wrote:
> >On Tue, Jul 28, 2009 at 08:05:15PM +0200, Iustin Pop wrote:
> >>Hi,
> >>
> >>I'd like to update ganeti to stable-proposed-updates to fix the above
> >>bug. It's a simple one-line change; I see only one potential breakage
> >>out of it - if people already did the symlink fix pointed out in the
> >>bug, but with the symlink pointing to a different version of Xen,
> >>then this version will change what xen version they use. More
> >> clearly: - if currently /usr/lib/xen points to anything else than
> >>   /usr/lib/xen-3.2-1, then
> >> - this upload will break people's HVM-based clusters
> >>
> >>Here is the proposed diff:
> >[…]
> >>Let me know if this is OK or not, or if you need more information.
> >
> >Ping? Did I miss some crucial information that is needed?
> 
> The one thing that concerns me is the potential breakage you raised
> yourself.  Is it possible to detect that the user has moved the
> symlink and leave it as-is?

Well, if we're looking at a minimal diff then not.

Basically, upstream has hardcoded /usr/lib/xen, but Lenny has
/usr/lib/xen-3.2-1. The current patch just changes the hardcoded path.

A flexible solution would be to change this to /usr/lib/xen-ganeti,
which would be a symlink created at package install time to point to
either /usr/lib/xen (if it already exists, which means users have
customized their system to fit the current buggy upstream) or to
/usr/lib/xen-3.2-1 (or the first xen directory found).

This would mean a bigger diff, and seems to me slightly worse than a
NEWS.Debian entry detailing the change; but granted, it would be
automatic. What is usually done in a such a situation?

Another alternative would be to abort install if /usr/lib/xen points to
something else. But this would be bad.

thanks!
iustin