On Mon, 19 Jun 2000, Bryan Paxton wrote:
> 1). deb yes just a tar.bz2 with shell scripts for install and uninstall. But
> what's wrong with this ? Look at FreeBSD ports.
I look at it.
I'm using OpenBSD and someday I will use rpm also on OpenBSD, promised!
> 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 : )
As I sayed: A rpm is always as good as its creator! ;-)
I've done some srpms which I can compile with different targets. The srpms
only build in my private environment but I can specify "target=i[345]86"
to compile on my developer box and I can also specify "target=m68k" which
does crosscompiling for Linux/m68k.
Yes, it works *always*. ;-)
[...]
> > > 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
Hey! You forgot "--nodeps"! ;-)
> 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.
But if you take care of it on creating the spec file by specifying "Requires"
and make a tough configuration of your rpm app (e.g. no auto-requires) then
you can build fine rpms - that kind of rpms I mentioned before.
That's IMHO *not* a rpm pb.
And it's still more powerful than deb-packages.
> 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.
Er... in this case above "--force" won't work IMHO!
> 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:
As I understand apt-get is a single application. You are comparing two
applications to one rpm application? I don't know much of the GUI and other
high-level stuff, but AFAIK there are of course applications for automatic
resolving of dependancies.
> 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.
What about mandrake-update?
> 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.
If downtime will cost a company much money then you can be sure that this
company will have RAID-arrays, separate production and test server and more...
> 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.
Then you should think over your strategy.
You are not speaking of a rpm pb, you are speaking of general thoughts for
administration of big systems.
> 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.
The desktop user has his/her nice, clickable, multi-colored GUI apps.
> So what now.................
Where's the problem?
Frank
-------------------------------------------------------------------------
Close the window, open the door, let in LINUX!
Sending unsolicited commercial email to this address may be a violation
of the Washington State Consumer Protection Act, chapter 19.86 RCW.
Das Verschicken unverlangter kommerzieller email an diese Adresse ist
verboten (LG Traunstein, 2 HK O 3755/97 vom 14.10.1997, CR 1998, 171f).
(Frank Meurer, <[EMAIL PROTECTED]>, PGP ID: 0x5E756DA8)
