|-----Original Message-----
|From: Bryan Paxton [mailto:[EMAIL PROTECTED]]
|Sent: Monday, June 19, 2000 5:43 PM
|To: [EMAIL PROTECTED]
|Subject: Re: [Cooker] RPM(s) worst enemy but Mandrake's best friend...
|
|
|I'm gonna go ahead and knock out all the replies out in one replied
|of my own.
|
|1). deb yes just a tar.bz2 with shell scripts for install and
|uninstall. But
|what's wrong with this ? Look at FreeBSD ports.
|
RPM does far more than DEB in this respect... pick up Maximum RPM for
starters...
|2). opts ? optimization aren't handled by RPM, they're handled by
|gcc(e.g.: -march=i586)
|Rebuilding a SRPM with --target= is almost useless in the
|situations I've encountered, ala it never works : )
|
Probably due to your insistence on mixing distros...
RPM is pretty good at keeping things straight, vis-�-vis dependencies, etc.
If you follow the guidelines your RPM's will normally rebuild without a
hitch, provided of course you've met their requirements...
I've rarely had one fail...
|3). LSB does advocate RPM as the standard for package management,
|RPM has a long
|way to go before it ever becomes the standard in a server
|environment though.
|Though mdk is not aimed at the server dept. either, so who knows
|on that one.
|
Well, let's see. Mandrake & Redhat provide "server" services. As a result
RPM has a preponderance of users. How do you define a standard?
Thanks I'll stick with RPM until something better comes along...
|Now, let's look at some of the things that could be improve RPM.
|
|Starting simple, in a previous post I read on here.
|
|> > rpm -Uvh gnome-libs-1.2.1-2mdk.alpha.rpm> > error: failed dependencies:
|> > libart_lgpl.so.2 is needed by ee-0.3.11-5mdk
|> > libart_lgpl.so.2 is needed by libglade-0.13-1mdk
|> > libart_lgpl.so.2 is needed by gnome-media-1.0.51-3mdk
|> > libart_lgpl.so.2 is needed by gnome-linuxconf-0.23-2mdk
|> > libart_lgpl.so.2 is needed by gtop-1.0.7-0.4mdk
|> > libart_lgpl.so.2 is needed by gnomba-0.6.2-4mdk
|
|What kind of dep handling is that ? As far as informative goes.
|I'm sure there is a simple hack to get rpm to list the package
|instead of the
|file name needed. This is one of the problems that make
|people(even users of rpm
|based distros) cringe.
|
What's wrong with this?
RPM is warning you that you are about to affect the other packages listed...
Had you dumped the corresponding updated RPM's into the same directory and
attempted to install them all at the same time, RPM would have handled this
for you all automatically...
|Also, how do we stop all the --forces ? I know from my brief
|experience with
|debian I _never_ had to force a package to install. The question
|is, is this
|a result of bad maintaining of the .spec files ? Or is this simply
|RPM's ugly
|side ? Remember, too many --forces can corrupt a DB and turn-off a
|user from
|even wanting to mess with said package.
|
--forces are normally the result of the user choosing to "step beyond" the
distribution. Since the new package which is being installed may require
some other lib etc. people often --force the installation.
This is akin to what the Winblows installers do... they merrily replace the
DLL's with whatever the current package needs, blithely overwriting
important system resources...
Deb is pretty weak in this respect, you can proceed without being "forced"
to do this...
Stick with packages built specifically for the distro, and you almost never
have to use --force. Or grab the src.rpm and build them yourself often
"adjusting" the resulting RPM to your own system.
|Runtime upgrades. No matter how ya look at it dpkg with apt is nothing but
|heaven. apt-get install and apt-get dist upgrade. apt-get install
|is convince but isn't this what mdk strives for ? dist upgrade is not only
|convince but less hassle.
Less hassle = bigger problems.
There is a choice that was made with RPM, protect the user from doing
anything stupid.
Deb does the opposite, assume the user knows what he/she is doing.
Sounds like you've been upgrading .debs a little too quickly...
You've been lucky so far...
|Lets say the next ver of mdk comes out, i have two
|choices on how
|to upgrade to 7.x. I can:
|
|1) Download a 650 meg ISO, burn it, pop it in, reboot and have a
|downtime of
|about roughly an hour or so.
|
|2). I can manually go get every package I need, then to find out
|that I need
|more packages to go along with the said packages to upgrade, which
|in turn would
|cost me about 4 to 5 hours of my time.
|
huh? I guess you've not tried gnorpm... but I digress.
Gimp goes to 2.0 which requires a slew of updates. Those updates in turn
"break" other applications on your system.
With DEB you can go ahead and install GIMP 2, breaking the other apps.
With RPM you are warned... yet you can still choose to overlook the warning
as you obviously do. It seems that you have done this so much that your
making the assumption that this is the correct way of doing things...
Well I have news for you... it's not!
|Doesn't this just seem ridculous ? It does to me. The only time i
|feel I should
|have to reboot of my own will is a kernel upgrade.
|
|Let's also look at this from a sys admin perspective if mdk ever
|wants to gain
|market in that dept. 1 minute of downtime could cost a company X
|amount of money
|as well as a lot of P.O.ed users/developers/whatever/whatever. So that
|virturally wipes out downloading the fresh new ISO or even buying a CD.
|
Faulty logic.
You're implying that DEB is unaffected by upgrade downtime... not so.
|What about option number 2 ? Sorry, but if had to sys admin a
|network of over at
|least 5,000 users I wouldn't want to spend 5 hours upgrading packages and
|kicking RPM because of useless deps.
|
Again failure to understand the process...
Deb is permitting you to install upgrades which it shouldn't.
RPM does not... no thanks I'll stick with RPM...
|Now let's look at this from a end-user perspective.
|Different scenario, same feelings. mdk is aimed at the desktop user, hence
|convince and friendlyness. Do the above and mentioned options of
|upgrading
|sound appealing ? Especially to someone likely coming from windows.
|
Again faulty logic.
The assumption is that Deb is immune for trouble during upgrades...
Since it monitors them far less than RPM it is more trouble prone...
This is why you are able to install so many .deb files in what you call
heaven.
|So what now.................
|
Use RPM as it was designed.
Start by reading Max RPM, you'll learn quite a lot.
You are enamored of a fault in Deb that seems like a blessing to you.
To a network admin this is real trouble. The last thing they want to do is
make 5000 systems unstable because of blytly updated libs...
Windows does this quite well already...
Sorry, I don't buy your arguments. Show me something better than RPM, then
we'll talk.
-JMS
