[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SEUL: Debian versus RedHat and DPKG versus RPM

Bill Thanis wrote:
> I believe everyone has lost site of the objectives here. The packaging
> of the distribution means very little. Anything that will do dependency
> tracking is acceptable. Also remember just because it comes in an RPM, or
> a DPKG package, does not mean it will work with SEUL. Most such packages
> in my experience have an implied distribution that it should go onto.
> Third party packages may come in the format we end up using, and still need
> significant work to get running.

Very good point.  Most packages will require at least some minor 
modifications to work with SEUL.  But also remember that SEUL is a complete 
paradigm shift.  Current distributions are geared towards getting technically 
competent people up and running.  This implies that there are toys and 
development environments available, as well as all the normal Un*x things.

SEUL is not a "hacker distribution".  It will be geared towards the end-user. 
Most packages out there (i.e. in the default RedHat or Debian installs) are 
not geared towards the end-user.  A perfect example would be SysVInit.  init 
is one of those things that's required for normal operation.  However, as it 
stands now, most distributions give you multiple run-levels, getty's on your 
virtual terminals, and commented out support for power-fail modes.

In SEUL, init will come out of the box configured for a default run-level 
with X or whatever else, plus single-user mode.  There won't be getty's 
running on the VT's unless you're in hack-mode (i.e. service-mode), as they 
aren't going to be used by Joe in Accounting.  The power-fail modes (for
UPS's) will be configured automatically, by a higher-level tool.

In this example, you can see that even the most common of all packages will 
need anywhere from minor modifications to major surgery to work in the SEUL 
environment.  Thus, whether or not we start from Debian or RedHat becomes 
less of a issue, as does the choice of package manager.

I most definitely agree with the 'shorter distance' concept.  RedHat and 
Debian, being geared initially for different markets, present different 
challenges as a base system when developing SEUL.  IMO, Debian is further 
from what SEUL is going to be than RedHat is currently.  I haven't installed 
it myself (yet; hopefully tomorrow), but everything I've heard so far tends 
to point in this direction.

> What the resultant system used by the user really has nothing to do with
> how it is installed. How things are installed concerns people who are
> creating upgrades for an existing system. In the windows world the answer
> to how things are installed has been to let the software being installed
> handle the installation.  Depending on the design of SEUL, this may be an
> acceptable method.

As you say, the package manager will only be heavily exercised - as it was
designed to be - during upgrades and single-package installs after the fact.
Because we will have a true package manager (vs. Slackware), this becomes
much more of a trivial task.  Depending on how packages get their
configuration into the system (via a registry-ish system, by dumping config
files in a directory ala sysvinit, etc.), the process can almost completely
be left up to the package manager.

Relative to doze, we have a significant advantage.  The entire concept of 
'package' and 'package manager' is completely alien.  As you say, when a 
program installs itself, it takes care of the details.  This generally means 
you can't un-install it or upgrade it as a result.  With a package manager, 
the details of which files go where, etc., are left up to the package manager 
itself.  No more hoping you del'd all the files, no more Uninstaller.  This 
will make users extremely happy.

However, we must also make sure that the RPM or DPKG format, whichever we 
choose, is used by both contrib-style developers and commercial entities 
alike.  If we don't, we end up with things like Adobe Acrobat and Netscape 
Navigator/Communicator that have their own installs that aren't necessarily 
verbose about their procedures nor careful about keeping records.  These are 
the packages that I truly hate.  I have a nice clean RedHat system, then I 
have to kludge Netscape onto the side of it in a chaotic manner.  Ugly.

We need to: choose a standard, be it RPM or DPKG; work with the original
author(s) as necessary to get whatever features we decide we need, if any; 
publish detailed specs on what other modifications/requirements we have, such 
as config-file locations (FSSTND), control-panel-ish control files, etc.; and 
make sure that contrib and commercial apps follow these guidelines in order 
to produce a larger base of software for the end-users.

Without these steps, we'll get stuck with a mediocre system that will 
end-of-life far too quickly for our needs.

     SEUL Project infrastructure/system architecture

        Erik Walthinsen - Programmer, webmaster, 3D artist, etc.   __
  __                                                              / /\
 /  \           omega@sequent.com         Work: (503)578-5314    / /  \
|    | M E G A  omega@aracnet.com         Home: (503)281-4281   / / /\ \
_\  /_          psu12113@odin.cc.pdx.edu  Majoring in CS       / / /\ \ \
                                                              / /_/__\ \ \
Omega Station: http://www.aracnet.com/~omega/                /________\ \ \
     Info on Linux, Graphics, Descent, Laptops, etc.         \___________\/

Simple End User Linux Mailing list
To be removed from this mailing list send a message to majordomo@txcc.net
with the line
unsubscribe seul-project
in the body of the letter.