On Tue, Jul 07, 2009 at 01:45:37PM -0600, Allan Lyons wrote: > Hi,
Hello, > I've been putting some thought into the linuxboot build system. There have > been lots of reports of difficulty in consistently > building releases because of interactions between the host system and what we > are actually trying to do. Some software, glibc in > particular, is hard to build and seems to interact with the particular > version of gcc being used. Our basic problem is that our > tool chain is getting contaminated by the host build system. > > There are roughly two parts to Unattended. One part is the necessary basic > infrastructure that we have to build in order to have > the tools to format the disk and get the intaller started. The second part > is the cool part that actually does all of the > installation. > > When we build the first part, what we are doing is basically building an > embedded Linux system that we then use to run our > installation scripts. This is actually harder to get consistently correct > than it seems at first. All we really need is a simple > consistent platform and it doesn't really matter what we use to get there. I > have an idea of how we can replace this basic > infrastructure with something that is actually easier to build. > > Since we are effectly building an embedded system to run the initial scripts, > it seems to me that we should be able to use > www.buildroot.org for the actual building of the boot environment. They've > already done the hard part of sorting out the build > system and tool chain. Also, most of the applications that we need are > already part of buildroot and it doesn't seem that it would > be too hard to add any other applications that we would need. > > If that works out, then it should be relatively easy to build new releases or > customize those parts for those who need to. > > So, does anyone think this would be a good idea to try out? I agree with the difficulty to build Unattended. Personaly, being able to build it with CentOS4 costs me a lot of time (nightmare: dosemu building ...), and my (dirty) CentOS4 hacks are not even enough to build glibc under RHEL5/CentOS5 :( In the other hand, I think that using a full cross-compiling env. is not necessary: it might take time just to configure it correctly, and it supposes also to maintain it: another layer, that you have to build first, even before untarring Unattended sources. IMHO, it should be sufficient to define and describe precisely what is the "official" or reference platform for building Unattended: linux distribution flavor, exact versions of gcc and glibc of the host system, etc. Then strongly inform the community about it, and loudly ask to use this one for anyone that want to build Unattended. Then we should provide this reference host build environment as an image of a virtual host, aka Virtual Appliance. As tiny as possible, such an image should make easier its adoption by the community. People will then keep their focus on enchancing Unattended instead of loosing time on build nightmares. After all, any Linux distribution with relative long term support should match our needs: RHEL/CentOS, debian or OpenSuse (excluding fedora or Ubuntu since their speedy release scheme and lack of long term support). Updating reference platform will be necessary from time to time, but less frequently than new linux kernel releases or glibc updates ;-) I bet on Debian (even if I don't know it). About virtual system format, OVF format should make happy both VMware and VirtualBox (and KVM or Qemu ?), that is a good starting point. my $0.02 (for the longest post contest ;-) Pierre Bourgin ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/blackberry _______________________________________________ unattended-devel mailing list unattended-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unattended-devel
