View Single Post
Posts: 69 | Thanked: 41 times | Joined on Feb 2010 @ Sweden
#1810
Originally Posted by zimon View Post
Roll back is not the only property which comes with transactions. Transactions makes package updates error tolerate. For example if battery goes dead middle of updating, or you drop your phone and battery flies off. When the system reboots, it can auto-correct the problem either finish the transaction or cancel it and tell the user that last action was not successful but it didn't broke anything at least. Or if some developer (maemo test and devel repos) forgets something and there is a dependency problem, after installation some other things are not working, user can rollback to the previous state and report the problem to the developer.
If the battery suddenly flies off (with no cap + interrupt-sync) you've got bigger problems with the filesystem to worry about than an update gone bad. You can always re-install the package(s) over the broken files, this process can also be automated.

Originally Posted by zimon View Post
Transactions is good to have in the package management, some people might think it is essential as the system state is pretty much like a critical database. Of course transactions feature can be disabled if there is good reasons, but I doubt in high end mobile phones there would be any. Anyway, rpm is in this way much better than deb, although in other technical ways they are pretty much identical.
You are wrong, file systems are a specific type of database that has worked very well for billions of people over decades. Dragging in concepts from the group-think of what sql is, isn't going to improve anything. The filesystem state is what it is, and the package manager doesn't see the whole picture, therefore "transactions" are a dangerous feature to have with little or no use.
Brain damage like this is what put people off from using RPM in the first place. The amount of times my systems used to get irrepairably damaged when I was using RPM-based systems in the past is horrifying.

Originally Posted by zimon View Post
I mean that in rpm-based systems nowadays it is a common practice to have all rpm-packages GPG-signed. GPG-signatures are embedded in the packages and do not get lost even if you transfer and install packages through ftp-program, wget, usb-stick, bluetooth OBEX transfer and so on and then install the package without alive connection to the original repository.

You can google lots of bad examples where people install un-authenticated deb-packages with dpkg -i. MITM attack on non-authenticated data (stream) is trivial if you have the skills.
That's why you check MD5/SHA1 on packages before installing, if you download them over an untrusted link.

Originally Posted by zimon View Post
The kludged way to embed GPG signatures in the deb-packages is not really used by anyone or anywhere. Show me where debsigs would be actively and routinely used, like embedded GPG signatures are used almost without exceptions for example in Fedora? Also it is important that developers have a standardized way to embed the GPG signature to the package release automatically.
Kludged or not, if we needed it in Maemo, we could simply use it.
Actively used is irrelevant.

Originally Posted by zimon View Post
There are many good things in LSB. Without them Linux would be even more fragmented it already is. And as said, if Debian+Ubuntu would had changed to use rpm-system long ago, Nokia now wouldn't have the problem with its developers implementing rpm support to Ovi and Meego. A good case of fragmentation in Linux which clearly causes troubles.
You talk as if there'd be something wrong with fragmentation, or as someone else would put it, having more than one choice.

Originally Posted by zimon View Post
Debian and Ubuntu (and some other smaller players) haven't just taken the fragmentation problem in Linux seriously enough, and now see, it costs Nokia lots of money and eventually may mean that Meego won't succeed because it was too late compared to Android.
No, more probably a major cause for the disruption in the schedule is the sudden decision to change to Meego, and preparations to change a package manager.
There's a reason distros don't do it, because almost all work needs to be redone.
Maemo was working fine, but needed some more dev-time which it never got, since everybody started to work on Meego.

No more strawmen please.