In a message dated: Tue, 07 Nov 2000 16:58:27 EST
Paul Iadonisi said:
> o I also like a single 'source package' file so all I need to do is move
> a single file to, for example, another hardware platform (netwinder
> anyone?) and type 'rpm --rebuild <source-rpm>' and voila! -- provided
> there are no platform specific fixes needed for the new platform, I
> have a new binary rpm. And I needn't fear that I've got the wrong
> dsc file paired my tar-gzipped file.
[...snip...]
> As a system administrator, I want to know that I can do batch installs
> or upgrades of packages without being prompted for ANYTHING. For the
> proper (IMO) way of doing this, look at what VMware does with its rpm:
[...snip...]
> This gives the installer much more control over the installation.
> Just install the freakin' thing and let me do ALL of the configuration
> later.
With the exception of a proprietary package in binary form only, why not just
use the source? I find it's almost always easier to install source when I
need to heavily customize a package than it is trying to work around the
brain-dead options some rpm/deb maintainer thought I should use.
The big win comes in when you have something which uses autoconf/automake, you
can run ./configure with all the "correct" options and then run make. Need to
install it on 8 different machines of similar architecture, tar the directory
up, move it to the other machines, a simple for loop at the command line
running rsh/ssh <machine-name>"cd <somewhere>;make install" does the trick.
> So you may say 'why not provide the feature and let the packager
> decide.' I know all the arguments about choice, in the Free Software
> world, but this one choice that should be up to the system administrator
> installing the package. Just take a look at the commercial products
> available for Solaris that are packaged with pkg tools, and you'll see
> that querying the system manager incessantly for information during
> the install is abused quite consistently.
I agree completely. And the reason for this, as Derek and I have often
discussed, is because these software houses, as great as their programmers may
be, are not sysadmins who have to actually install and deal with this software
in a large and complex environment with very site-specific requirements. They
test their installation process in a lab with one, maybe two machines, and they
just make sure it works. They never allow for the possibility that the machine
you're installing on:
- isn't the system it's going to run on
- isnt' a pristine installation with other things installed
- may not be the system you're actually sitting in front of
(ever had an install fail because:
if [ ! "$DISPLAY" = ":0.0" ]
then
exit 1
fi
)
- may be set up to have all software installed on an NFS mount
rather than the local disk (NetApp boxes really through some
installation sw for a loop :)
I'm completely amazed by their total lack of cluefulness. You'd think that
there would be enough sysadmins like us out there complaining that their
people would wake up and fix things! And don't get me started on the idiots
they call Sales Engineers who come in to your site to "Assist" with the
installation. If those people "helped" me any more, I'd be better off not
installing (I'm still trying to figure out why we've abandoned the abacus :)
As for which is better, dpkg or rpm, I think it depends upon what you want.
RPM has many nice features, as does dpkg. I know nothing about building
packages for either of them, so I can't help you there. I've just moved over
to Debian on my work system (I'm still running RH at home), and from a user
perspective, I've found I like apt/dpkg alot better than I do rpm. While I
know how to use rpm better, and learning the apt/dpkg combination seems to
involve reading a lot more man pages than did rpm, I think the combination is
far more flexible over all, and provides for much easier package installation.
--
Seeya,
Paul
----
I'm in shape, my shape just happens to be pear!
If you're not having fun, you're not doing it right!
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
