Re: SEUL: RFC: Base SEUL on Debian?

[Rick Jones <rickya@siservices.net>]

Erik Walthinsen (Omega) wrote:
> 
> Reply-to: omega@seul.org <!!!>
> 
> On Fri, 16 Jan 1998, Rick Jones wrote:
> 
> > I'm curious why you aren't just starting from scratch?
> We aren't starting from scratch because I do not want to wait 2yrs to
> release SEUL.  Debian exists, is stable, is well-supported by the
> community, and intends to move in mostly the same direction as SEUL.

I don't see why it would take 2 years to get a core together from
scratch, since I did it in about a month without knowing what I was
doing, I just kept reading ho-to's and README's.  It was like 3 years
ago though.  I agree that Debian, at this point is *it* when it comes to
the most complete, well done dis' out there.  Note I didn't say
user-friendly.

> The problem is that they still are not the same.  Note the contrib/ fiasco
> on ftp.redhat.com.  I don't think it's fixed yet.  When rh5 was released,
> there was a rush to get packages in contrib/ rebuilt for 5.0.  But one
> thing was forgotten: 4.2 users.  I wanted to install tcl/tk 8.0 for some
> development work, but *after* downloading it found that I couldn't,
> because it was built for a glibc (rh50) system.  Nowhere now can I find
> rh42 compatible RPMs.

I assume the problem was either that RH 5.0 went to glibc6 (Debian) from
glibc5 (Debian) or the dependancies wouldn't allow it.

> Granted, a core will not elliminate these problems, but they will be much
> less of an issue.  contrib/ RPM's would be built for a certain group of
> versions of the core, and would then work on any and all distributions
> based on one of those core versions.

How is that going to work given that any one eliment of the core can be
revised at a different time than the other elements?  You going to hold
a bug fix or security fix until the next core version?

> > I know you have been talking with Bruce about this, I don't know who
> > else, but Bruce is no longer in charge of the Debian project.
> I know, but he's coordinating between Debian and many of the other
> projects, which is his role as head of the SPI.

I see,  I've been out of the Debian loop for a while traveling around
installing VSAT WAN's.  All I knew is that Bruce was out.

> You're not understanding the idea of a core.  Debian/SEUL/eLinux/others
> would design the core, and be built around it.  This core is nothing more
> than the bare minimum necessary to define a system for versioning and
> compatibility purposes.

So you're not talking about the core binaries needed for a base system? 
You're just talking about an outline for versioning the binaries each
dis' decides to put in their individual core/base installation even
though those could contain differing binaries?

> > The only way a commercial dis' is going to follow your lead is if they
> > become the odd man out that can't run commercial software packages.
> Exactly.  Commercial distribs (i.e. RedHat) won't switch unless there is a
> clear reason why it's better.  If the major free and upcoming distribs
> (Debian, SEUL, e-Linux, etc.) form a core standard, and get vendors to
> port to it, RedHat is left with little choice but to switch, just to
> maintain their ability to hold customers.

Right now, it seems that Red Hat is the dis' of choice.  So it seems to
me the first problem is going to be to become more popular than Red Hat
before the software vendors are going to care that there is a core
implemented.  That means suppoting RH 100% but also augmenting the dis'
to provide attractive app's that RH doesn't provide in addition to ease
of configuration that surpasses RH.

That is probably why RH is against this and will fight to remain above
you.  So they are going to disreguard your core idea until the very end
and possibly implement their own in competition with you.  Be advised
that an idea can be patented and most likely will not fall into any
aspect of the public licenses.  So if RH, or anybody else, patents the
idea for this core they can slam the door on your effort to unify
Linux.  I believe Bruce holds some Linux patents, he would be a good one
to ask if the core it's self can be patented.  If so, a dis' wanting to
keep Linux free should patent it first.