Re: SEUL: Common SEUL/e-linux tools needed

[Erik Walthinsen <omega@omegacs.net>]

> 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.)
Keep in mind, however, that the best results to be obtained from a full 
hardware emulator (not a JIT recompiler) are about 5 times slower than the 
hardware itself.

> 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.
I've never had any trouble, and the newer versions are even better.  It is 
under active development, as well.

> 	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.
Almost every RPM in existence has a corresponding SRPM file.  Only if the 
author decides not to ship the SRPM is it not there.  rpm will create the 
SRPM by default.  Second, RPM is designed *specifically* for unattended 
compiles.  In fact, you can't build a binary RPM unless it is completely 
automated (well, you can fudge it if you're very, very careful).

> 	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.
Nope, we just include the file in the SPEC for the RPM.  Simple as that.  
Requiring that a given file (config, in this case) exist is simply not in the 
scope of a package manager.  That's not what it does.

> 	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
> 		consistancy too...)
This is a feature, no?

> 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.
Not true.  rpm (and/or dpkg) do everything we need.  There is no need to 
write YAPF (yet another package format), and I have no plans to do so unless 
it is demonstrated that indeed there are features that we need that cannot be 
added to either rpm or dpkg.  IMO, if we end up in that situation, we need to 
start over and rethink what the heck we're doing.

> 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...
Why?  We can't assume that the SPEC file or equiv will work on a new .tar.gz 
(original source) unless that package is already set up precisely for that 
purpose (as should be the case for our own software).  For production 
systems, the only thing that is needed is a check for new, upated, packages, 
as we find in RedHat.  There are several contributed packages that do just 
that.


Having just seen your repost, I will simply say that you are describing RPM 
to the letter.  If you don't believe me, buy or download Maximum RPM 
(www.rpm.org).

     Erik Walthinsen <omega@seul.org> - SEUL Project system architect
        __
       /  \                SEUL: Simple End-User Linux -
      |    | M E G A            Creating a Linux distribution
      _\  /_                         for the home or office user