[packagekit] PackageKit & Debian, Was: External dependencies, DeviceKit-power and GNOME Power Manager

[Josselin Mouette]

Le mercredi 26 novembre 2008 à 13:23 +0000, Richard Hughes a écrit :
> On Wed, 2008-11-26 at 13:24 +0100, Martin Pitt wrote:
> > A typical question is the one for an administrator password when
> > installing things like mysql or a wiki.
> 
> I don't think this is a install time thing, it's a configure time thing.

This is where the distributions’ philosophy vastly differ. Red Hat
thinks this is a configure time thing, but in Debian this is an install
time thing. Red Hat has the policy to install a lot of things and let
people configure and enable them later, while in Debian, you install a
package only when you want to use it.

> I think in this case the best thing to do would be to use Message(),
> something like this:
> ________________________________________________________________
> |
> |  Password Required
> |
> |  A default password is required for the 'mediawiki' package.
> |  This needs to be set in /etc/mediawiki/defaults before
> |  the service is able to be used.
> |_______________________________________________________________

That would be a huge regression. Currently the post-installation script
will automatically setup the database and the application with the same
password, for example. This is not possible this way.

> If we allow this kind of interaction, then we forbid the unattended
> update use case. If the user walks away and leaves the PC on, the screen
> locks. The session schedules an update. The update happens, and the
> package manager puts up a prompt.

We already have a tool for unattended upgrades, that skips any upgrade
that would require user interaction. The same policy could be adopted
for unattended upgrades done with PK, or we could simply not do them
with it.

> I do think this problem is solvable tho:
> ________________________________________________________________
> |
> |  File conflict needs to be resolved
> |
> |  Updating samba-server has modified the /etc/samba.conf file
> |  which has user modifications.
> |
> |  [ Ignore ] [ Show more information ]
> |_______________________________________________________________
> 
> This again can be shown at the end of the transaction, and the "more
> information" box can call a helper script, something like
> pk-resolve-file-conflict.sh.

In the meantime, the samba server might have been restarted with a wrong
configuration.

> This can prompt the user with a full merge GUI, or just use a simple
> zenity based solver. The fact that debconf asks you mid-transaction is
> an implementation detail, rather than something that needs to dictate
> the end user interactions required.

That solver would have to be aware not only of the modified files, but
of the actions it needs to take after resolving the conflict. That’s not
as simple as you suggest.

> I'm not aiming to replace apt-get, aptitude, yum or any other native
> tool; There will always be things that PK cannot do and the distro tool
> will always be faster, more complete, and more interactive than what
> PackageKit is able to do.
> 
> PackageKit doesn't aim to 100% replace all package management tasks for
> all types of users. Trying to do that would be pretty insane as all the
> backends are quite different.

We are eager to replace both update-manager and synaptic (which can do
the same things as aptitude, really) with a tool that would be
feature-complete and with a proper design. It would be a waste to do it
as a separate project when so much effort has been put in PackageKit.

> I might sound like an asshole here, but I'm not going to be bullied into
> putting functionality in which blocks a transaction.

But on the other side, we are not going to embrace a tool that does not
have this functionality.

So this really means that we will have to develop and maintain a fork if
we want to integrate PackageKit in our desktop.

Cheers,
-- 
 .''`.
: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://lists.freedesktop.org/archives/packagekit/attachments/20081126/cb80057b/attachment-0004.pgp>