[WBEL-devel] Heads up on RHEL Update2 Beta

[Milan Keršláger]

On Wed, Apr 14, 2004 at 12:14:45AM -0500, John Morris wrote:
> On Tue, 13 Apr 2004, Milan [iso-8859-2] Ker?láger wrote:
> 
> > You don't need extra partitions. All is able to live in chroot
> > environment without need to reinstall base system. With yum this is easy
> > to check if all updates/packages are in place (see list option).
> 
> Hmm.  I had heard that RH did it with a chroot.  I have had problems with
> grub in a chroot (rescue) before though and figured it was more thing that
> could go wrong.  Guess it is worth trying, then all I'd need is a spare
> spot to do test installs.

There are the same problems with packages like in "fresh installed"
system (needs to be builded as non-root etc). When building no package
should need access to master system. If you have a problem with grub,
try to (re)install package in chroot with --noscripts --notriggers.

> > If your build system is AMD64, you are able to build full clean i386
> > system in i386-only chroot tree and vice versa (AMD64 build needs clean
> > x86_64 tree with no i386 stuff).
> 
> Haven't started researching what I'll need to do to get AMD64 builds.  So
> you are saying that if you install the 32bit compatibility layer so you
> can build i386 packages you can no longer build native packages?  Oh boy,
> life on the bleeding edge!  Guess if I use a chroot environment to build
> in it won't be that bad, but I pity the normal developer trying to support

There are few broken packages in x86_64 and you need to handle them even
you don't use chroot (wrong autodetection in configure etc so you will
need sometimes to install glibc.i386 package and sometimes you will need
to remove it, but safe is to have plain x86_64 tree except for
exceptions). Chroot is about
I-do-not-need-to-reinstall-system-many-times. It simply save your time
when you are know what you are doing and does not need to sit behind
building machine and walking through installation process again and
again.

> I think this is the way to go, because after pondering it some more I have 
> hit a problem with the original scheme.  If I create a 3.1 tree I'd have 
> to keep it up pretty much forever because I have already noticed up2date 
> go back for packages from the base set to install errata.  So I'm now 
> figuring on keeping up2date pointing at the 3.0 tree.  Any packages which 
> differ in the respin should be in the errata directory anyway so 
> everything should be good.  So all that will be in the 3.1 tree will be 
> .iso images.

You was talking about rebuilding whole WBEL. Don't do it. It is only
wasting of time and throwing away QA you and others did here (even we
are unable to track bugs in something like Bugzilla). Every rebuilded
package could be badly linked or miscompiled (because configure bug or
so).

If you underestand this, you will leave current packages as-are-now, add
U2 like others errata, don't make 3.1 and only respin ISOs to save time
for downloaders.

There is really no reason to have 3.1 because 3.0+updates = 3.1 (so
there is no difference and no need to bump version except confuse
non-experienced users who will try to "upgrade").

> Ok, questions for those who know more about this stuff than I do.  Way I 
> see it there are three ways to get a chroot environment.
> 
> 1.  Install a system, then copy the whole live tree over.
> 
> 2.  Try to use rpm --initdb --root [path to chroot] then install enough
> packages with rpm --root [path to chroot] to get self hosted.

This is not easy like this because scripts (i tryed this already). The
safer method is to install minimal system, use tar for backup (except
/proc and the directory where you are putting backup). Then transfer to
build system, extract, chroot to new tree, mkdir /proc, mount /proc and
/dev/pts and then run yum (to update system and installl the rest) by
using something like this:

$ yum update
$ yum list | awk '{print $1} > to-install
$ vim to-install  # remove kernels, glibc for other archs etc
$ yum install $(cat to-install)

Maybe I forgot something but this is the major working schema.

> 3.  Copy the running system's tree.  Sounds like a bad idea.
> 
> Opinions as to which is safer, etc. welcome.

-- 
                        Milan Kerslager
                        E-mail: milan.kerslager@pslib.cz
                        WWW:    http://www.pslib.cz/~kerslage/