On Sun, 2005-02-06 at 18:00 +0000, Ian Pratt wrote:
> > > > --home causes python's distutils to install into
> > > > /usr/lib/python/, while
> > > > --root causes it to install into
> > > > /usr/lib/python$ver/site-packages, which is the more correct
> > > > location.
> > Er, in all packages I have ever used, make dist has given me a
> > tree(which is normally placed into a tar by upstream, and
> > 'dist'ributed, hence the name), that can then be optionally
> > overlayed ontop an already installed system.
>
> Yes, but its quite usual for bpeople to install Xen on a different
> system to which is was built (e.g. our binary install tar file).
> Installing into /usr/lib/python/ means that it'll be found on the
> module search path, whereas /usr/lib/python$ver/site-packages will
> only work if the version is the same.
Brian wrote in reply:
>Mind please that I have no empirical proof, just personal experience
and opinions/preferences >expressed to me by admins I know.
>I would have to disagree here. If Xen is to be taken seriously in a
commercial environment, then >it's going to have to be available as a
dist binary from either redhat, suse, debina, or another top level linux
distro IMHO.
>Having to compile things for every machine tends to turn potential
users off that aren't programmers or gentoo/*bsd afficianados from my
experience.
>Heck, this is why I stated packaging 1.3 in the first place. I just
couldn't deal with deploying by hand every couple of days. I really
needed it to be automatic as possible.
Administrators in custom environments (of which a Xenoserver hosting
facility is one) usually have to build their own custom packages. All
major distributions like the ones you describe provide adequate tools to
automate this process, and to automate package deployment across
multiple servers. It is not a big deal for a competent administrator to
generate a custom package for specific purposes. Relying on distribution
packages can in many cases leads to problems (ie when upstream has a new
version but the maintainer refuses to update the package, or when there
is a license conflict and the new version of a package cannot be
included in the mainline distribution).
The Xenolinux kernel itself (as generated by the install script) is
technically difficult to package due to the inherent problems in
autoconfiguring grub (as im sure you discovered during your packaging
excursion).
I think the real answer to this problem is to provide a Xen installation
cd that in turn can install any of the mainline distributions from their
distribution CD into a dom0 and/or a domU. Changes to individual distros
architecture to support Xen (Fedora anyone?) will come in due time, and
certainly the other distos will quickly realise the need to include Xen
support as its popularity increases.
Tom
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home