[bt-devel] RFC: Remove modules installed by the native package manager

[Eeli Kaikkonen]

Sveinung Kvilhaugsvik wrote:

> I have heard that people have complained about not being able to
> remove modules that are installed by the operating system's native
> package manager. The following patches are a possible solution to it.
> It adds support for PackageKit, an abstraction layer for package
> managers, to BibleTime. The support is behind #ifdef's and won't be
> enabled unless CMake can find PackageKit. If it's enabled at compile
> time it will still check if it can use PackageKit during runtime
> before it will use it. Since PackageKit use dbus and dbus has
> different bindings I don't think this belong in Sword. If you are
> interested I'm willing to work more on it to get this code in a state
> where you can commit it to BibleTime.

OK. Since now we have heard positive and negative comments. Most of us 
know that there was a heated and even hostile discussion about the 
subject on the sword packager mailing list. There's no need to continue 
it anymore, at least unless someone has something really new to say. But 
I still repeat some points here. And most of my opinions stated after 
those repeated points have also been expressed before during this 
discussion.

First, the great problem was the dependency: the application(s) depended 
on the text modules. It caused problems. These dependencies have been 
removed, so there should be no such problems anymore. This is the major 
point because it affects greatly to the need for a solution.

Second, the packagers have right to package what they want, even text 
modules. There are some reasons to do it and there's no reason to repeat 
them anymore.

Third, even though they have the right, they should not in the opinion 
of the majority of the application developers. There are several good 
reasons for that and there's no reason to repeat them anymore. I 
personally also oppose packaging the modules. Still we have to live with 
the fact that there are modules packaged for some systems, and they can 
be useful for many users.

Let's not start fighting about these anymore.

Now, back to the first point. If the module packages are not installed 
automatically, they are installed manually and only by the admin. 
Therefore we have right to suppose that it has been done on purpose and 
that the one who installs also knows how to uninstall using the package 
manager.

In my opinion the integrated package management support doesn't give us 
anything very useful. People don't expect that applications have a 
built-in system package management capability. If a user/an admin can 
see that a module has been installed with a package manager, he 
naturally opens the system package manager. If the user doesn't have 
admin rights (root access) he can't remove the module anyways.


Scenario 1: Multi-user environment. Admin has installed some modules 
with package manager. A non-admin user uses BT.

The user opens the bookshelf manager. He notices that some modules can't 
be uninstalled because he doesn't have privileges. Well, he's out of luck.


Scenario 2: A non-admin user who has also admin access (normal single 
user Linux scenario) has installed some modules with package manager. He 
uses BT.

The user sees that he doesn't have privileges for some modules. They 
have a notice: "this may have been installed with the system package 
manager". He remembers he have installed them with the package manager. 
He opens the package manager as an admin and uninstalls them. OR he 
gives his password and uninstalls the packages via built-in PackageKit 
support.


Scenario 3: An admin who has installed some modules with the package 
manager uses BT as an admin.

What happens now? If BT detects only the file permissions, it doesn't 
still know that some packages have been installed with the package 
manager. The admin can remove package data without knowing it if he 
forgets it's been installed with the package manager.

If BT uses PackageKit it's probably able to detect the packages and 
notice the admin. Or even prevent removing the files only. The latter 
option is safer but needs more code. PackageKit support would also allow 
removing the packages after detecting them.


I think that scenarios 1 and especially 2 are common use cases, but 
scenario 3 is not. People shouldn't normally use end user applications 
as root. If they do, it should be only temporary, happen for some 
specific reason, and they should know what they are doing. If an admin 
wants to install sword modules site-wide he can do it with BibleTime or 
with some other frontend, but he's responsible of the whole thing. If he 
mixes the package manager and BT bookshelf manager, it's his own business.

Some people have said that if an application allows removing the files 
installed by the package management system, it's broken. I don't agree. 
Is a command line shell broken because it allows rm -rf / ? The admin 
must know what he's doing. We can't be babysitters.

So, only the scenario 2 is the one which we should directly support with 
PackageKit, if any. But as I said, there should be no automatically 
installed modules in the system. If there are, it's a horrible bug in 
packaging. And if there are not, the one who has admin rights should 
know how they have been installed and how they can be uninstalled. 
Giving a note in the BT UI gives them a hint that it's time to open the 
package manager. If we use PackageKit he can just give his password and 
remove the modules.

But is this case so common and is the PackageKit so much easier that we 
should support it? I would say it's not worth it, but you can still 
persuade me.

Actually hundred times more important is to implement the warning about 
non-removable files. Additionally, this warning/marker/whatever is 
needed anyways, with or without PackageKit. Sveinung: dare I ask you, if 
you are still interested and have time, to implement this prerequisite? 
In first incarnation it should only detect those packages which can't be 
uninstalled by the user, detecting the file permissions. It should of 
course be coded so that it enables detecting the packages with 
PackageKit with minor changes later. If you are interested, we can start 
discussion about the UI details. We don't have to make any final 
decisions about the PackageKit support yet, but I won't take it in 
without this prerequisite.

--Eeli Kaikkonen