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

Re: LPI and Distros...



For fun, you might want to look at this:

  http://www.luci.org/luci-discuss/msg00071.html

I was making the same arguments 7 years ago...

On Sun, Jul 18, 2004 at 06:21:05PM -0000, Brandon Joseph Adams wrote:
> As a slackware user I have to respond. There is standard package
> management. It is very simple, in the pkgtools with no dependency
> checking.

That's not package management, that's tar.

"Package management" implies dependency checking, conflict checking, a
way of upgrading/removing/downgrading packages *cleanly*, etc.  rpm
has all of that.  dpkg has all of that.  Even HP-UX's swinstall has
all that.  Slackware's tools have almost none of that.

> If you don't like the spartan package management, build your own from
> tarballs. There is no difference in customizing something for slackware
> using ./configure than editing an rpm.spec for Red Hat/Mandrake/SuSE/etc
> except that ./configure is not rpm-specific.

Which is exactly what Slackware users do (and have always done)

Keep in mind, I was a Slackware user for several years, a decade ago.
*Nothing* has changed in Slackware, even though the rest of the world
has.

> The QA is up to the administrator and the package designer. If you would
> use known good packages (e.g. don't use a random gcc build to bring up
> your system), you don't have quite as many problems. Interactions still
> need to be understood. That's one of the reasons the admin is paid.

An admin is also paid to make good decisions.  In my mind, an admin
should know better than to waste time building things from source,
testing, etc., when there are other people volunteering or getting
paid to do that job.  :-)

> I'm not seeing how userbase matters. For example, because Steve's rpms
> don't have a lot of users, does this mean they are bad? Of course not. I
> use them, along with a lot of other people on this list.

First of all, most of my stuff has actually been tested more than you
might realize...  Most of the stuff I build is for various clients.
Also, nearly all of the stuff I make available has been submitted to
fedora.us for QA approval, so I like to think my packages are pretty
good.

> Slackware has their own, much simpler init system. The init system is
> mainly a thing of preference.

BSD-style init is an unmaintainable mess.  It's not simpler by *any*
stretch of the imagination.  It's actually *ridiculously* complicated
compared to SysV init, which simply uses a bunch of symbolic links to
determine what gets started/stopped at any given runlevel.

This is one place where I will give Gentoo some points...  Their init
system isn't standard, but it is interesting.  It has dependency
checking, so that if (for example) the portmap service has to start
before the nfs service, then the nfs service can just say that portmap
is a dependency, and it will automatically be started in the right
order.

While that's pretty neat, I don't think it necessarily requires
tossing out standard SysV init.  I've often thought of hacking the
equivalent functionality into Red Hat's init scripts...

Steve
-- 
steve@silug.org           | Southern Illinois Linux Users Group
(618)398-7360             | See web site for meeting details.
Steven Pritchard          | http://www.silug.org/

-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.