Re: [Lsb-build] Need an lsb chroot build environment with real libsinstead of stubs.

Bart Whiteley <[email protected]> (by way of Bart Whiteley <[email protected]>) Tue, 3 Feb 2004 20:16:52 -0700
Newsgroups gmane.linux.lsb.implementation
Organization Novell, Inc.
Message-ID <[email protected]>
On Tuesday 03 February 2004 06:50 pm, Wichmann, Mats D wrote:
> > I'd like to set up an LSB chroot build environment for all my
> > packages.
> > There's a slight problem with the lsbdev-chroot solution.  In
> > my RPM build,
> > I compile a tool, then execute the tool within the RPM build.
> >  Since lsbdev-chroot
> > only gives me access to stub libraries.  I can't execute the tool.
> >
> > It seems to me that what I need is LSB-si + build tools.
> > This way I would have
> > real libraries instead of stubs, so I can execute my newly
> > compiled tool within
> > the RPM build.
> >
> > I can take LSB-si and lsbdev-chroot and start to build such
> > an environment.
> > I'm sending this email to see if anyone else has already done
> > this and can give me some advice.
>
> There's some work afoot to add build tools to the lsbsi.
> I've added the lsb-impl list to this thread for that reason.
>
> Is there a good reason why the alternative build toolkit
> (lsbcc) doesn't work for you?

I'd prefer to use chroot.  I like to set up a build environment that
is NFS exported read-only.  I usually set this up by installing a distro
with a devel installation profile, then rsyncing the whole thing
to a directory on a NFS server.  Users can then NFS mount this,
chroot into it (with a little magic to make /tmp and /root local filesystems
mounted rw instead of NFS).  This way multiple developers can use
the same build environment, but they use their own CPUs and disks
instead of a community build box.  They don't have to worry about corrupting
a local build environment.

See the attached email I pulled from the rpm list (the archives are
PW protected so I didn't just send a link).

> It was designed for the
> situation where more tools are needed than are provided
> by the chroot, in particulat the GNU-configure type
> arrangement where lots of things that aren't part of the
> LSB need to run before the build can actually proceed.
>
> Actually more feedback on what would make the chroot more
> useful would be appreciated... you've begun that process
> already, thanks.  What libraries are you using that are
> not found at run-time?  The lsb stub libraries are still
> only pulled in at link time, and the ordinary versions /ought/
> to be available at runtime. If not, the existing tools
> (gcc, etc) wouldn't be working either!  If there are only a
> few extra libs needed, you can import them into the chroot via
> the config file, or arrange to link those libraries statically.

I wondered how the compiler, etc. would work without real libs.
I thought they might be statically linked.

To be honest I didn't experiment with lsbdev-chroot much.  When
I started it with the init script, I got a few errors.  Then when I ssh'd in,
I tried a df and got lots more errors.   I don't know if these were expected,
or if I did something wrong.  Since it seemed to be broken I didn't spend
much time with it.  From reading the docs I assumed that real libs wouldn't
be available in the lsbdev-chroot environment.

At any rate, I'd prefer to build an environment that I can use as described
above an in the attached text instead of lsbdev-chroot.

Thanks.


--
Bart Whiteley <[email protected]>
Novell, Inc.  The leading provider of information solutions.
http://www.novell.com/

_______________________________________________
lsb-impl mailing list
[email protected]
http://freestandards.org/mailman/listinfo/lsb-impl
chrootbuild.txt (text/plain, 3.7 KB)
From: Bart Whiteley <bwhiteley novell com>
To: rpm-list redhat com, Simon J Mudd <sjmudd pobox com>
Subject: Building RPMs in common chroot environments (was) Re: Cross-building a binary RPM package - is it possible?
Date: Fri, 5 Sep 2003 12:32:28 -0600
 
 
You probably thought I left you hanging so long ago...

I won't share the script.  It's got a bunch of hard-coded stuff 
anyway that wouldn't work in your environment.  I will explain
what it does.  You can create your own script just as easily as
you could fix mine.  

First, install a box and get it all set up the way you want 
your build environment.  Install onto a single partition
Then, rsync the whole partition to a directory on an NFS server. 
Hint: you'll probably need to be running from a different partition
to do this.  Either install on another partition, boot into that, and
mount the partition you want to rsync, or use something like 
knoppix.  Make sure you are root on both sides of the rsync, 
and use rsync -a.  Otherwise your device files won't be 
properly created. 

Now, in the dir containing the rsynced build system on the NFS
server...

mv root RealRoot; ln -s RealRoot/ root
cat << EOS > /etc/rpm/macros
%_topdir /root/rpm
%_tmppath %{_topdir}/tmp
EOS

Now any old linux box running any old distribution
can become a build environment.  You'll need a script
that does the following:

- Create some temporary work dir like TDIR=/var/tmp/chrootBuild.<pid>
- mkdir -p $TDIR/.mounts/{local,nfs}
- Obtain a directory from the user, or use some default.  This is where
  the sources will live and where the building will be done.  Let's call 
  it WDIR
- mkdir -p $WDIR/rpm/{BUILD,RPMS,SPECS,SOURCES,SRPMS,tmp}
- mount -o ro <nfs server>:<path to rsynced build env> $TDIR/.mounts/nfs
- mount <local partition contianing $WDIR> $TDIR/.mounts/local
  parse the output of 'df $WDIR' to get the partition
- cd $TDIR
- ln -s .mounts/nfs/* .
- rm root tmp proc
- mkdir tmp proc
- mount -t proc proc proc
- Now you need to make root a symlink to the work area. 
  This is the part that's just a little tricky.  You need to chop
  the mount point off of $WDIR.  For instance, if $WDIR is /root/code, 
  and /root is on it's own partition, you need to isolate "code" so you
  can do 'ln -s .mounts/local/code/ root'
- now just 'chroot $TDIR'
- once the chrooted shell exits, clean up (unmount stuff in $TDIR/.mounts, etc.)

All of the filesystem is read-only except for /root and /tmp.  What
was previously $WDIR is now in /root.  The RPM topdir is 
/root/rpm.  This way many engineers can share the same build 
environment.  They can't hurt the build environment.  They
use their own CPU cycles and disks instead of sharing one 
machine.  They can use their favorite distro (I prefer debian)
on their workstations instead of needing to run the distro 
that they are building for. 

I hope somebody finds this as useful as I have.  I'd be happy to 
answer any questions about it (this time in a more timely manner). 

On Monday 28 July 2003 11:40 am, Simon J Mudd wrote:
> [email protected] ("Bart Whiteley") writes:
> > Yes.  I have a script that sets up the mount points, creates
> > the symlinks, and chroots into the new virtual environment.  It
> > also takes as an argument a command to execute one it is
> > chrooted into the new environment.  This way you could launch
> > a build from cron or whatever.
>
> Would you mind sharing this script with us please?
>
> Thanks.
>
> Simon
>
>
> _______________________________________________
> Rpm-list mailing list
> [email protected]
> https://www.redhat.com/mailman/listinfo/rpm-list

-- 
Bart Whiteley <[email protected]>
Novell, Inc., the leading provider of information solutions
http://www.novell.com/