On Mon, 19 Jun 2000, Frank Meurer wrote:
> 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*. ;-)
>
heh *nod*
> [...]
> > > > 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.
>
Once again *nod*
> > 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!
>
hrmmm ? what won't work ?
> > 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.
*nod* but why not jump in ahead to offer something appealing and easy to manage
for the sys admin ?
> > 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.
>
Most of these apps completely suck IMHO.
The functionality is horrible as in what it can and can not do.
The only decent one I think is out there is kpackage(which I refuse to use at
this moment for other reasons other than functionality, *cough* QPL *cough* : )
)
--
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
