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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
