Is performance the most important factor here?
|
| Author | Content |
|---|---|
| caitlyn Jun 19, 2009 2:52 PM EDT |
I have no doubt that yum is slower than apt. Should I really care? With a package management system (rpm or deb) my big concern are things like how well dependency resoultion is handled during installs, upgrades, and removals. Are orphaned packages detected and removed? Are you warned of any additional breakage you may cause? In these areas yum and apt are equals. I have always felt that the .spec file system used by rpms is the most flexible and comprehensive way of controlling the package management process from a packager's perspective. Yes, you can do pretty much anything with a Debian package that you can do with the rpm. I just feel the structure of the rpm system makes it easier to understand what others have done when picking up a complex package from someone else and lends itself to orderly, well organized coding of processes needed by some complex packages. Again, I don't doubt Chris' findings. I just wonder if they represent the primary concern. Normally I'm all about performance. In this case... not so much. |
| rijelkentaurus Jun 19, 2009 3:25 PM EDT |
Most users will never see the frontend or backend of the system, just the little ticker in the system tray that says "Hey, update me!". And they'll do so, never paying enough attention to know if it's fast or slow. Yum is substantially slower than apt. And apt-for-RPM (think PCLOS) is even slower (IMO). But I agree, who cares? It's not like one is done in five seconds, one in an hour. Meh. Someone needed to sell ads. |
| hkwint Jun 19, 2009 7:19 PM EDT |
Quoting:Are you warned of any additional breakage you may cause? Lately that's just what 'apt' did to my fresh Debian-Lenny Experimental (paradox I'm afraid?) install. I wanted to install vesa 2.0, it gave some errors and solutions with scores below zero, but I didn't understand it was going to hose the whole system to being totally unusable. It didn't warn me. Probably my ignorance. Anyway, I assume most people don't watch while their system is upgraded. Unless you're a fan of hours of gcc-mess scrolling by, but those people are an exception I guess. I belong to those exceptions however, I have always liked Win98' simply because of the screens full of moving rectangles during defragmentation - which lasted hours and started again if you started the browser. XP was worse than 98, because it didn't provide the moving squares by default. Most people however go sleeping after they started to update their computer* or do defragmentation, so to them it's not much of a problem. |
| krisum Jun 20, 2009 2:41 AM EDT |
Quoting: I have always felt that the .spec file system used by rpms is the most flexible and comprehensive way of controlling the package management process from a packager's perspective. Yes, you can do pretty much anything with a Debian package that you can do with the rpm. I just feel the structure of the rpm system makes it easier to understand what others have done when picking up a complex package from someone else and lends itself to orderly, well organized coding of processes needed by some complex packages.Having created both rpm and deb packages, IMO a deb package is decidedly more flexible and powerful as is creating one. The problem with .spec file is that it is unnecessarily cluttered with information on how to build the package, changelog etc. By contrast, the separation of debian's rules, control, changelog, conffiles make things clean and simple, and also allows a packager to use a build system of choice. Also, deb format has a few things lacking in RPM like Suggests, Recommends (I think this one is there in RPM now), Conflicts, Tags, dpkg-divert etc. Additionally debian has a number of practises which make things much more streamlined like virtual provides, meta-packages, alternatives (picked up by Mandrake, jpackage), debconf, copyright and changelogs etc. |
| caitlyn Jun 20, 2009 11:45 PM EDT |
Quoting:The problem with .spec file is that it is unnecessarily cluttered with information on how to build the package, changelog etc. By contrast, the separation of debian's rules, control, changelog, conffiles make things clean and simple, and also allows a packager to use a build system of choice. I actually find that, for me, splitting it all into separate files is a decided disadvantage, particulary if following on someone else's work. I like having my package and build instructions inline. A well written .spec file isn't cluttered. It allows you to look at what was done, how it was done, and the results. rpm does support package recommendations and has for some time. It also allows several different categories of dependencies (arch specific, build only, etc..). Meta packages have been available in rpm for as long as I can remember. Conflicts are also well supported. Changelogs have been around forever. It looks like you have a personal preference for Debian packages which is fine. You haven't mentioned anything I can't do in rpm and, as previously mentioned, I still find the spec file system superior. That is my personal preference. I will also note that rpm is the LSB standard. |
| krisum Jun 21, 2009 7:18 AM EDT |
Quoting: Meta packages have been available in rpm for as long as I can remember.Except that RedHat/Fedora does not make good use of it (madriva does make better use last I saw). Hence it was not mentioned as a missing feature rather as a practise in debian. Same goes for things like virtual packages, alternatives, debconf, defoma etc which can all be implemented in rpm but are not. Quoting: rpm does support package recommendations and has for some time.Really? I found this in one of suse's rpm but last I had read on Fedora's and rpm spec guide there was no support for recommends, suggests, enhances etc. Do you have any reference for this? Quoting: Conflicts are also well supported.Yes, I erroneously mentioned "Conflicts" as missing feature -- i should have rather mentioned it as a practise in debian that is consistently followed. Quoting: You haven't mentioned anything I can't do in rpmNoted some of them in previous post: * fields like Tags, Suggests, Recommends (still adding last two since afaik these are not in standard rpm) * dpkg-divert * ability to use a custom build system (not to be confused with the build system of the software) e.g. cdbs, dpatch There are others like conffiles (thereby allowing one to have something like ucf), pre-depends, breaks, enhances. OTOH, you have not provided any reason for the claim "rpms is the most flexible and comprehensive way of controlling the package management" apart from being your preference. When you say "flexible" then one would expect you to provide an objective reason and "easier to understand" does not make something more flexible. From my side, it has been mentioned that creating debs is more flexible due to the generic rules file that allows one to use any build system (again not to be confused with the build system of the software). |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!