From: Tim Post <echo@echoreply.us>
To: Dulloor <dulloor@gmail.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: linux distribution ?
Date: Thu, 21 May 2009 18:27:20 +0800 [thread overview]
Message-ID: <1242901640.5451.286.camel@localhost.localdomain> (raw)
In-Reply-To: <940bcfd20905210253h2251363ejc779368e704cbe8@mail.gmail.com>
On Thu, 2009-05-21 at 05:53 -0400, Dulloor wrote:
> Keir et al -
>
> I am on ubuntu and every time I upgrade my distro (dom-0), I end up
> spending half-a-day getting xen working again, like this time on
> moving to jaunty/karmic (problem booting 2.6.18 based xen and then
> python version).
>
> Which distro do the xensource guys use for their development ? All I
> am interested in is xen development/test environment.
>
> -dulloor
You might consider just building Xen from source (tools and hypervisor),
which takes it completely out of the scope of your package manager.
I know that is taboo in some circles, however it gives you greater
flexibility when upgrading, while also giving you the ability to test
experimental patches.
The problem is, doing this often violates enterprise warranties. 99.9%
of the time, I'd rather just trust my distro when it comes to packages.
When it comes to Xen, I usually recommend (and install) the latest
faithful official release. The one and only time I just used distro
packages was with Ubuntu Hardy (LTS) .. and that was chaotic (time going
backwards, etc).
There was once a universal installer script .. can that be resurrected
and possibly rely on m4 being present for developers? Using that, the
user knows with no uncertainty exactly what they are missing (and what
version is needed).
For instance, a dependency on 32 bit stubs when building on x86_64.
It does not have to be named ./configure, it does not have to create
makefiles and I am happy to maintain it. The drawback is 6k+ lines of
generated shell code that has to be tracked in the hg.
It could be ... scripts/checkbuildconfig .. or whatever. It would not be
a configuration tool, just a diagnostic tool that offers hints on what
is needed to build.
Why clutter the Makefile needlessly? A script would be more portable,
anyway.
This approach has solved this exact problem for decades.
Cheers,
--Tim
next prev parent reply other threads:[~2009-05-21 10:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-21 9:53 linux distribution ? Dulloor
2009-05-21 9:57 ` Patrick Colp
2009-05-21 10:16 ` Dulloor
2009-05-21 10:27 ` Tim Post [this message]
2009-05-21 10:41 ` Dulloor
2009-05-21 10:42 ` Tim Post
2009-05-21 23:38 ` Dulloor
2009-05-21 23:45 ` Dulloor
2009-05-21 23:47 ` Patrick Colp
2009-05-22 6:29 ` Dulloor
2009-05-22 8:18 ` Patrick Colp
2009-05-22 9:57 ` Michael David Crawford
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1242901640.5451.286.camel@localhost.localdomain \
--to=echo@echoreply.us \
--cc=dulloor@gmail.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.