🚀 go-pugleaf

In <m2sot8e41w.fsf@reddwarf.aup.com.au> Manfred Bartz <mbartz@werple.net.au> writes:

>I disagree on this point.  While all distributions have their own
>idiosyncrasies, the ones relying heavily on package management are
>much more problematic.  

Can you give an example of where the idiosyncrasies are problematic?
I'm running almost all systems on RedHat prepackaged code now and have
probably saved hundreds or thousands of hours of building, testing,
copying and installing stuff. Most ``raw'' packages (e.g. .tar.gz files
in the GNU ftp archives) are packaged for reasonably easy building and
installation -- on a single host. They don't readily lend themselves to
being built on one host and installed on many; you then get to invent
your own duplication mechanism.

>That is precisely why I recommend against packages.  I personally
>don't want to rely on someone else to keep my computer running.

What exactly is it about cat(1) or ghostview that you can't trust
anybody else's prepackaged version? If it doesn't work,
uninstall it and build one for yourself from the original sources.
It's not like these programs are the crown jewels -- the chance of
the first one not working is so close to 0 it's unmeasurable, and the
second is a highly optional application.

I've argued on both sides of this argument, by the way. In the past I
was a staunch advocate for building packages from the original source;
it means I know in detail which directories it uses, for example.
However I don't buy the reliance argument because it's trivial to
uninstall something which doesn't work.

>For a
>newbie it is hard enough to determine where the problem is without
>package management.  Packages introduce an additional layer of
>complexity or, for a newbie, shroud of fog.

Actually they simplify things. Scenario: ghostview doesn't work. Why?
It's not installed. So install it. Ghostview works. Problem solved.

I said above I use RedHat. I place a fair amount of trust in them; I
trust they won't put a backdoor into cat(1) or ghostview. This trust
is not misplaced - they've established a fine reputation as a source
of reliable working systems. The chance of getting an RPM from them
which plain doesn't work is about 1 in 300 (I've installed about 300
different RPMs and only 1 plain did not work). It's unlikely that they
will go out of business in the near future (and leave me with a bunch
of RPMs which are never going to get updated by somebody else) but if
they did, I'd be no worse off than before I started using prepackaged code.

>If I have installed an application from a tar-ball as opposed to a
>RedHat or Debian package, then I know at least where everything is,
>what options I enabled and what changes I had to make (if any).

This is a strong argument for "building it yourself". But do it where
it makes sense to do so - like Apache, where you choose which modules
are going to be built with the server binary.

The other strong argument is that it "builds character". It's hard to
debug stuff which doesn't work if you don't even have the skills to
compile it yourself.

>I am not against packages, they have a role to play as an advanced
>system administration tool.  I will probably invest some time and
>learn how to make packages myself.  Being able to do my own packages
>will give me leverage and at the same time make me less reliant on
>other package maintainers.

Yep. And it helps a lot when you're maintaining many hosts.

>LINUX -- where uptime is counted in months.  Reboots are for kernel updates.

... and adding hardware.

Nick.
-- 
Kralizec / Zeta Microcomputer Software  Fax: +61-2-9233-6545 Voice: 9837-1397
G.P.O. Box 3400, Sydney NSW 1043        http://www.zeta.org.au/