Now, OBS is certainly something more reasonable than the community/license talk, but doesn't OBS do .debs lately ?

Someone has made quite good arguments regarding RPM.

https://bugs.maemo.org/show_bug.cgi?id=9067

Do not talk about it in bugzilla, but in here please. I have no adequate skills or knowledge to speak about this, but Bartosz Taudul seems to have collected his arguments in quite good list.

voted - I don't care.

i want an open linux computing platform, i will get one either way.

i am an opensuse user anyway, so rpm is no barrier, nor too is the code similarity to fedora rather than debian.

my only concern is that n900 community development is not left to wither on the vine because of the radical differences between freemantle and meego.

One radical difference is a switch from GTK+ to Qt... this will cause a huge drop in developer headcount.
Switch from Debian to Fedora (it's not just a package format - it's the whole surrounding ecosystem) is another radical change causing a developers drop.

Will the developers coming from Qt and Fedora domains equalize this?

i am delighted about the switch to QT, because i believe it is a much better strategy for the future. this is a change that must be made, and will bring a great number of benefits.

I'm no RPM guru, but I'm sorry to say that almost all of those arguments are the results of the author not being familiar enough with present day DEB/DPKG and not the advantage of RPM.

Can you elaborate? I would be interested in seeing the points he makes rebutted.

The bottom line is things are done differently, so the actual preference is HOW you do something, not WHAT you are doing (that's why the whole DEB/RPM dispute is bogus).

1. I think apt-get dist-upgrade does exactly what he describes. In additions there is an (admittedly seldom used) selection mechanism using which you can specify exact packages to operate on, see dpkg --set-selections (and it's friends, get a and clear) plus apt-get dselect-upgrade

2. This is a default policy. rm -rf / will not tell you you're likely killing yourself either. You have --dry-run if you have doubts what the result will be.

3. sounds like --unpack

4. He doesn't like the debian/debhelper docs. If debian docs are too dry, Ubuntu has very nice packaging tutorials/guides which lack the 'BS' he disapproves of.

5. This has nothing to do with deb. It's just the way debhelpers work - preferring a multi-file setup to a singlefile one, I don't see how this is an objective technical disadvantage. You could unify the debian dir into a single file and build debs from that, nothing deb specific there.

6. dpkg-statoverride (or dh_suidregister). No idea what he's talking about when says it's difficult to make multi-binary releases from one source, all debhelpers do/handle this by default.

7. 3rd party apps. No bearing on deb, anyone can make a superfast deb-based thing too. H-A-M being slow because of all the apt-wrapping is Nokia's choice of not implementing any extra layer of indexing/caching (which is exactly what the 3rd party applications do).

8. debhelpers know about --prefix and dpkg itself has --instdir, it was (again) Nokia's choice to use special /opt handling instead.

That's it in short, off the top of my head. To reiterate, I don't really care either way, just that preferences of doing someting one way does not mean another way of doing the same thing is wrong.

I can address a couple I believe:
This is somewhat confusing to me. But I believe shows an utter lack of understand of apt (from the man page):
Edit: Oh, I see - he only wants to do a "apt-get upgrade" of certain packages. I guess I've never run into this problem.

This is actually a matter of preference. Having dpkg behave in this way allows me to then do "apt-get -f install" to automatically download and grab the dependencies for that package, and then properly install all of them. No dependency hell (meaning tracking them down myself, or yum installing them one by one), so to speak. What is the equivalent of this in rpm?

His #3 about scripts is an interesting perspective. But it can be both good and bad. This is entirely based on the packager and whether he did a good job or not: But a *lot* of proper uninstallation can be put into prerm scripts and thus, if you don't run them, would leave your system in a very flakey state. If there's an error in the script, then it's obviously a problem, but skipping the script altogether may not be the best answer (although the option *should* probably be there..) because there is no telling what the install scripts could have modified that the remove scripts should be fixing without going into the script and reading it.

As far as his Build documentation (#4), that's entirely perspective. I have never had a problem finding the necessary how-to's to building a deb file properly or the proper formatting of the files.

The Build files (#5), again, never had a problem with this. And the nice thing about the debian/rules file is you can manually edit the exact steps needed to compile a piece of software: in case you get something that is written using a strange system other than cmake/qmake/automake/etc. I personally like having separate files, it's cleaner and easier to read, than a single, long, file to accomplish the same thing.

Somebody else will need to address 6.. I don't understand how RPM can magically allow a user to suid root a binary that debian can't. This looks like something that should be taken care of in a postinst type script and can only be done as root... and the .deb takes and packages up the files with the permissions that they were given when you build the deb package - so if you suid the binary as root, build the deb, and then install it - it will come out suid. I don't understand what he's getting at.

#7 - Speed. Um... ok? There's helpers for RPM.. and there's helpers for Debian... so... who cares?

#8 - Tries to simplify a complex problem. You can't just dump your binary into /opt/whatever-you-want because /opt is not in the $PATH of the users. So, in addition to redefining the prefix to install to (which, by the way, is perfectly possible by editing the debian/rules file to pass whatever prefix options you want), you also need to symlink the proper binaries to the rootfs. Until and unless there is an official and standardized directory structure to place executable binaries: such as /opt/bin and not /opt/package_name or /opt/usr/bin or /opt/MyMommyThinksImSpeshul... etc. Currently I haven't found anywhere that says "This is the exact opt structure your app should look like" - so what we end up with is 30 different applications optified to 30 different sub directories and they can't all be added to the users $PATH unless every application is written to modify that variable every time. I don't see any benefit to using RPM's __prefix over just add --prefix or CMAKE's prefix commands to debian/rules.

#9 - bells and whistles: Yay? I'm sure dpkg/apt have a few RPM don't as well.. what's important here is the basic structure of package installation and dependency management.

At this point.. in those specific developments.. it doesn't matter if you have DPKG or RPM.

The main thing that matters, as has been repeated many, many, times - is the actual structure of the filesystem and OS. I personally have never liked SuSE, Mandrake's, or Red Hat's structure. I also have had no end of trouble using Yast or URPMI and up2date.

However, I've never had any complaints with YUM. So I don't care if either YUM or APT-RPM are used in the new system - they both work fine for me. As long as the OS structure makes sense.

the few things i noticed:

apt-get upgrade maybe??
(at that point i already knew he doesn't really have much experience with debian packaging...)


dpkg -i won't install stuff without dependencies. you have to --force-things or --ignore-depends for that to happen.
dpkg -i without either of those additional parameters will fail when encountering unmet dependencies.


dpkg --force-remove-reinstreq


mhm...
centralized debian documentation > fragmented rpm documentation IMO


now that part's a rant from someone in unfamiliar territory, nothing more.


that's a maemo-specific problem. actually, it's an application-manager specific problem. has nothing to do with apt/dpkg helpers. (apt-get install something in xterm will NOT trigger a DB rebuild, it IS cached).


i doubt that just using .rpm and prefices/macros will magically solve this problem. many things won't "just work". that's hopelessly optimistic