| |||||||||||||
RPM -- plans, goals, etc.RPM -- plans, goals, etc.Posted Dec 15, 2006 9:22 UTC (Fri) by k8to (subscriber, #15413)In reply to: RPM -- plans, goals, etc. by mattdm Parent article: RPM -- plans, goals, etc.
You say feature, I say bug. The problem is that rpm can end up with multiple versions of the same package installed whether or not this makes any sense. In the debian world you have to explicitly allow the possibility for various versions of the same tool to be installed, where it makes sense.
This trades for a different problem where you want to (as a special case) install two versions of something that only makes sense in your circumstance. In RPM you might be able to do this and not break things, or things might break. In deb-world, the system just refuses.
I prefer the packaging system that refuses to do nonsense actions, over the one that lets me take nonsense actions that might happen to make sense sometimes.
(Log in to post comments)
RPM -- plans, goals, etc. Posted Dec 15, 2006 12:29 UTC (Fri) by mattdm (subscriber, #18) [Link] I'm not sure your preference is really helpful. Any powerful system will let you do some things which are nonsense. The bug here is that if RPM dies in the middle of an upgrade transaction (power loss, or hardware error, or software bug), you'll end up with some of the new packages installed but the old ones not yet removed. This boils down to the earlier issue of partially-installed packages -- there's not really a problem with allowing duplicate packages per se.
RPM -- plans, goals, etc. Posted Dec 15, 2006 13:07 UTC (Fri) by drag (subscriber, #31333) [Link] Ya but how can it work out that i have two versions of a libsdl lib installed?
How does RPM deal with that conflict? Were in the filesystem are these two things support so coexist.
It's all confusing and mysterious to me.
The only other thing that bugs me is the unbearable slowness of Yum. I know it's python and all, but I also use GUI python apps that feel nearly as fast as anything else.
This lead me to the original problem I had. I have a older machine that I use CentOS on as a desktop at work. It's very old, probably 300 mhz or whatnot.
Normally the speed is irritating, but it's mostly a glorified terminal so it's not a big deal.
But there was a bunch of updates flashing on that little red button and I decided I needed to update it.
I thought I gave myself enough time, but I underestimated the unbareable slowness of the beast and after a while I just plain ran out of time and had to cancel the upgrade.
A week later I was able to get back to it and lo it took me freaking 3-4 hours to resolve the issue. I work evenings and I didn't get finished with the stupid thing until like 4 or 5 AM in the morning.
gaw...
(otherwise I like CentOS)
Maybe you (or someone, maybe I'll look at but I can't make any promises, it'll take me a few months to figure out this stuff as I am no programmer) need to rewrite the math-intensive portions or something in C or Pyrex and import it back into the program as a module. I expect that there is only certain functions that take up 90% of the time..
RPM -- plans, goals, etc. Posted Dec 15, 2006 13:29 UTC (Fri) by rvfh (subscriber, #31018) [Link] What bothered me most when I had to use CentOS 3 was that For deb users, it's as if
RPM -- plans, goals, etc. Posted Dec 15, 2006 14:47 UTC (Fri) by smoogen (subscriber, #97) [Link] Interesting. This must be a configuration option then as most of the Debian systems I have helped maintain had to have a 'apt-get update' run before I could get useful information. I wasn't the primary admin so this could have been something the other admins did for some obscure reason.
RPM -- plans, goals, etc. Posted Dec 15, 2006 17:57 UTC (Fri) by Zenith (subscriber, #24899) [Link] > had to have a 'apt-get update' run before I could get useful information
What he meant was that what rpm does is LIKE apt doing an 'apt-get update' first every time you used apt. It does of course no this, as it is, well, annoying :)
RPM -- plans, goals, etc. Posted Dec 15, 2006 20:27 UTC (Fri) by drag (subscriber, #31333) [Link] The first thing about yum that I learned was the '-C' (or is it -c?) option which runs it using cached information so it doesn't pull down new headers each time.
RPM -- plans, goals, etc. Posted Dec 15, 2006 21:02 UTC (Fri) by Zenith (subscriber, #24899) [Link] Neat, I did not know about that little trick, which probably comes from the fact that I have spent way too little time administrating a Fedora/Red Hat system :)
But thanks for the tip anyway.
RPM -- plans, goals, etc. Posted Dec 15, 2006 15:07 UTC (Fri) by smoogen (subscriber, #97) [Link] In the case of multilib packages, it works it out because one is an .i386 or .i686 and one is a x86_64. It then upgrades the right one. To see what the packages are in each listing you can do a 'rpm -ql <package name>'.
The unbearable slowness of yum is not something I can help with. Especially the older yum that is on the Centos-3.8 boxes.. the difference in speed with python gui and python yum is one is dealing with a database and the other is moving pixels.
RPM -- plans, goals, etc. Posted Dec 15, 2006 20:41 UTC (Fri) by drag (subscriber, #31333) [Link] Well that's what I was saying about pyrex.
Python is one of those things that kicks-ass and is plenty fast, but you have to know it's limitations.
One of those is dealing with a lot of math and such. Lots of intense calculations is not good for it.
So the basic idea of it is:
It's just what you do. This is why it's possible to use python for things like programming game logic and physics. It's used by all sorts of stuff like that.
Rewriting stuff in C is a huge pain in the ass though. So they invented Pyrex. Pyrex is something were you have a python-like syntax, but you can do C-like syntax also and it's something you have to compile. It's specificly designed to create python modules.
Doing straight compile from python-like code doesn't offer much of a performance enhancement, but with proper optimizations and such you can actually get within the realm of pure C program.
There have been cases were pyrex is faster then C because you don't need a lot of the boiler-plate code and it's cleaner and more easier for the programmer to understand.
Of course you would like to avoid using Pyrex and such and do as much as you can in Python before you give up on it, otherwise with inapropriate use of pyrex can defeat much of the benifits of using python.
http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/
http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/...
RPM -- plans, goals, etc. Posted Dec 16, 2006 23:14 UTC (Sat) by seyman (subscriber, #1172) [Link] > In the debian world you have to explicitly allow the possibility for> various versions of the same tool to be installed, where it makes sense.
In the debian world, the package naming conventions demand you add the most significent version number to certain package names.
|
|||||||||||||