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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2012-11-09 at 19:55 +0000, Matt Wilson wrote:
> 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.

That's one option. If the list could be autogenerated (e.g configure
doing install.sh.in -> install.sh) then that might make it less prone to
problems.

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

Our configure seem to provide --libexecdir and I think packagers on
platforms which don't use /usr/libexec (e.g. Debian & derivatives) are
probably pretty used to passing that option.

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

I remember now, yes deferring from 4.2 was the right thing to do but now
that 4.3 is in swing this seems like as good a time as any to be making
a change like this.

Ian.


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