On Mon, 19 Jun 2000, Jose M. Sanchez wrote:
> |-----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...
>
I'll grant you this.
> |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...
>
heh no, snag say glibc*.srpm && rpm --rebuild --target=whatever
watch the gcc flags....
> |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...
RPM server is nothing but a security hole and a slew of exploits waiting to
happen, why do you think noone uses it ?
>
> |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...
>
You by far missed the point on this one.....
The warning message does not display what package lib* is part of and what
you are breaking. Though this is due to poor spec maintaining I assume.
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.
>
--forces are every day life for 99.9% of all users using an RPM based distro.
Go to an irc newbies channel and count how many people come in with these
problems. This again can also be traced back to poor maintaining of spec files.
> |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.
if [[ $less_hassle == $bigger_problems ]]; then
echo "Lay out all possible problems that one would encounter with a dist upgrade
and elminate the source of the problem"
else
echo "Let's stay in the stone age"
fi
> |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.
You're gonna compare gnorpm to apt ?
That's apples and oranges man.
>
> 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.
It sounds like you haven't played with dist upgrades a lot.
WARNING messages are given if one package will break another.
>
> |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.
>
Sorry, I've never had to or seen a box taken off line during a dist upgrade.
> |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.
How should it not ?
apt-get dist upgrade is a simple choice, you don't have to do it.
And why shouldn't it offer upgrades ?
I suppose 100 buggy packages aren't worth upgrading huh ?
>
> |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.
>
Every package management system as of now as it's goods and bads, I've never
had a problem with dpkg/apt, though I have had to help remedy situations where
an upgrade did break something(perl) on the system. Fact goes without saying
that this can and does happen in mdk as well, this box is living proof of
upgrade from 6.1 to 7.0. the difference here is I was able to salavage the deb
box and not the mdk box, I had to go back in and do a complete re-install.
The rest of your post was poor flame and I ignore it : )
--
Bryan Paxton
"How should I know if it works? That's what beta testers are for. I
only coded it."
-- Linus Torvalds.
Public key can be found at http://speedbros.org/Bryan_Paxton.asc
