[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SEUL: Common SEUL/e-linux tools needed
> > Linux Emulator:
> > will emulate a virtual linux system, allowing
> > a safe environment to test-install packages that
> > must install and run as root... It may be nice to have
> > a version for each hardware platform...
> > This will run as batch, so speed isn't a concern!
> Actually, a full chroot'd environment works perfectly for this. I have
> built several complete, booted-the-first-time systems on alternate
> partitions using this method. Simply do alternate-root rpm installs of
> the first few required packages, chroot to it with an NFS mount handy
> inside the root, and install away.
Well, for one thing, this is supposed to help catch non-well behaved programs.
Also, I would like to be able to check the program on all five popular Linux
hardware platforms (ix86, m680x0, PPC, Alpha, Sparc/Ultra ) through emulation.
Specifically, the ix86 cannot fully emulate itself... it can only emulate
a 8086/8088 in a Virtual CPU. I think not doing a full emulation is
particularly dangerous for programs intended to run as root... (Not to mention
that a full emulation of the ix86 might give the Wine project a boost.)
> Baring poorly behaved applications, this is a very secure, safe
> rubber-room environment to do just about anything you want. IMHO, RedHat
> should be using it for RPM builds. If found out last night that the perl
> 5.004_01 rpm in the biltmore updates was set up with a BuildRoot of
> /var/tmp/perl_root. How do I know this? None of the CPAN modules would
> work, as Config.pm still pointed to /var/tmp/perl_root. Major oversight,
> which I will be mentioning to RedHat tonight.
I'm quite hesitant to go with RPM for several reasons:
1) I have found that the 'rpm' program from RedHat seems to keep
records poorly, and is easy to confuse.
2) I dislike that most RPM that are availible don't contain
source-code, and the ones that do don't compile
automatically in the background.
3) I think that if we want to have plug-in modules for this
configuration tool included with *ALL* packages, then
we need to have a new format that gaugentees that such
a file does *INDEED* come with each package.
4) The PGP key, and the integrity checking will provide a moderate
level of security (protecting the user more from developer
laziness, than developer hostility, but providing some
I posted something to e-linux a while back concerning this, I'll see if I
can dig it up...
I do realize that creating a new package format for our distributions will
lead to an *HUGE* amount of work for all of us, but I do believe it necessary.
Most likely *WE* will have to originally adapt each .tgz file to each package
until the developers themselves decide to champion this... On the bright side,
however, the server system I envision will monitor the .tgz and attempt to
automatically update when the program is updated...
I'll try to dig up that old e-linux post...