[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Bugs in xl that affect stubdom+tapdisk2, and others



On Fri, Nov 09, 2012 at 01:29:04PM +0000, Ian Campbell wrote:
> On Thu, 2012-11-08 at 20:45 +0000, John Weekes wrote:
> > As an additional note about 4.2 -- this isn't an "xl" issue, but rather 
> > a build problem -- even though I use "./configure --libdir=/usr/lib64", 
> > the build is still creating a "dist/install/usr/lib" directory, and 
> > because of this, running ./install.sh nukes my system's "/usr/lib" -> 
> > "/usr/lib64" softlink (which in turn causes all sorts of other problems 
> > until it's corrected). Files that are being put in that tree:
> > 
> > xen-4.2-testing.hg # find dist/install/usr/lib
> > dist/install/usr/lib
> 
> This is an interesting one. I'm not sure how we can avoid this
> behaviour, perhaps there is a tar option to cause it to follow rather
> than clobber synlinks?
> 
> The only other choice I can think of is to change install.sh to use a
> (long) explicit list of $(FOO_DIR)/* entries instead of the single * to
> avoid including system directories, or to otherwise make install.sh more
> fragile and prone to bitrot :-(

Oh dear. If we find that there's not a good reason for it anymore, I'd
think it would be better to remove install.sh instead.

> I must confess I didn't realise anyone used install.sh -- is there some
> advantage to it over make foo-install?
> 
> OOI which distro has this lib->lib64 link and what issues does removing
> it create?
> 
> > dist/install/usr/lib/xen
> 
> This is $(XENFIRMWAREDIR). I have a feeling there is a reason this is
> not using $(LIBDIR), but I don't recall what it was -- Roget/Matt do you
> remember?

There's no need for these files to be multilib compatible, as they are
not runtime DSOs. They're internal to Xen and I think that they should
be moved to $LIBEXECDIR instead, like /usr/libexec/xen/. Unfortunately
there's not much agreement on the usefulness of /usr/libexec, so we'll
need to make sure that packagers can adjust the paths for their
systems' standards.

For 4.2 we didn't want to change where these files were being placed,
and I believe they've bin in $PREFIX/lib/ for quite some time.

Matt

> Thanks again for reporting all these.
> 
> Ian.
> 
> > dist/install/usr/lib/xen/boot
> > dist/install/usr/lib/xen/boot/xenstore-stubdom.gz
> > dist/install/usr/lib/xen/boot/ioemu-stubdom.gz
> > dist/install/usr/lib/xen/boot/pv-grub-x86_64.gz
> > dist/install/usr/lib/xen/boot/hvmloader
> > dist/install/usr/lib/xen/boot/pv-grub-x86_32.gz
> > dist/install/usr/lib/xen/bin
> > dist/install/usr/lib/xen/bin/stubdom-dm
> > dist/install/usr/lib/xen/bin/qemu-io
> > dist/install/usr/lib/xen/bin/qemu-nbd
> > dist/install/usr/lib/xen/bin/qemu-img
> > dist/install/usr/lib/xen/bin/xenpaging
> > dist/install/usr/lib/xen/bin/qemu-dm
> > dist/install/usr/lib/xen/bin/qemu-system-i386
> > dist/install/usr/lib/xen/bin/qemu-ga
> > dist/install/usr/lib/xen/bin/stubdompath.sh

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.