[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.
TTYAL,
Omega
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.
----------------------------------------------------------------------------