Tom Hibbert
2005-Feb-07 20:24 UTC
Packaging Xen (was RE: [Xen-devel] debian python-install.patch (3 of 5))
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 experienceand opinions/preferences >expressed to me by admins I know.>I would have to disagree here. If Xen is to be taken seriously in acommercial 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 potentialusers 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 justcouldn''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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel