I'm gonna go ahead and knock out all the replies out in one replie 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.
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 : )
3). LSB does advocate RPM as the standard for package managment, RPM has a long
way to go before it ever becomes the standard in a server enviorment though.
Though mdk is not aimed at the server dept. either, so who knows on that one.
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.
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.
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 convience
but isn't this what mdk strives for ? dist upgrade is not only convience but
less hassle. 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.
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/managment/whatever. So that
virturally wipes out downloading the fresh new ISO or even buying a CD.
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.
Now let's look at this from a end-user perspective.
Different scenario, same feelings. mdk is aimed at the desktop user, hence
convience and friendlyness. Do the above and mentioned options of upgrading
sound appealing ? Especially to someone likely coming from windows.
So what now.................
--
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
