[packagekit] Status of the APT backend

[Josselin Mouette]

On mer, 2008-02-20 at 18:05 +0000, Richard Hughes wrote:
> > Well, I guess I have to disagree with Richard about the Debconf needs.
> > When a question comes with a high priority, it does need to be asked.
> > When you get a big fat warning telling you to reboot, it should not be
> > ignored.
> 
> There's a standard abstraction method available for this. Please see the
> documentation for RequireRestart().

Currently this is done through debconf. That means jumping through
incredible hoops if you have to detect which messages ask you to reboot.

> > High priority questions (which are thankfully rare) are for
> > things that don’t have a sane default, in which case noninteractive
> > installation isn’t going to work.
> 
> For example? If it's not going to be something my mother can understand,
> then please don't quote it as an example. 

Description:  Do you want to abort removal now?
 You are running a kernel (version ${running}) and attempting to remove
 the same version. This is a potentially disastrous action. Not only
 will /boot/vmlinuz-${running} be removed, making it impossible to boot
 it, (you will have to take action to change your boot loader to boot
 a new kernel), it will also remove all modules under the directory
 /lib/modules/${running}. Just having a copy of the kernel image is not
 enough, you will have to replace the modules too.
 .
 I repeat, this is very dangerous. If at all in doubt, answer Yes. If
 you know exactly what you are doing, and are prepared to hose your
 system, then answer No.

The wording could definitely be better, but I’m sure your mother would
understand the question - and abort the removal. I know that this kind
of information should be available directly at the PackageKit level, but
there is currently no way to obtain it without actually running the
prerm script.

> BTW, I don't see any problem
> with a message saying:
> _______________________________________________________________________
> [ A package may require configuring                                   ]
> [                                                                     ]
> [ A package you've just installed by require options to be set before ]
> [ it will work correctly. [Click Here] to configure.                  ]
> 
> Which links to an executable that does the debconf stuff. I think it
> would suck from a user interaction POV, but if it has to be done, it has
> to be done.

As you say, it sucks. And it would still require proper dbus integration
of debconf for a clean implementation, which is the only hard part of a
full-fledged debconf integration.

> My personal and technical view is that stuff should just work out of the
> box - if it's something like httpd then it's not insane that an admin
> will have to configure stuff using system-config-httpd or editing
> apache.conf before it works.

Indeed, things *should* just work out of the box. But they don’t always
do, especially when doing a major upgrade.

In all cases, this is certainly not the first thing to be worried about
until the APT backend works properly, but we should make sure that there
are no fundamental design flaws preventing integration of such crucial
functionality.

> > I’m interested in PackageKit as a potential replacement for Synaptic,
> > and I dare to say that it will never replace it without proper debconf
> > support.
> 
> PackageKit isn't a replacement to synaptic. It's just not designed to
> be. It's designed to make software easier to install and keep updated
> using a cross desktop and cross-distro API. Synaptic does a fantastic
> job on debian, but just isn't a tool new users should be forced to use.

Synaptic isn’t suited for new users because of its UI which is too
complex, not because of its features. Furthermore, everything is run as
root, which works but has many flaws. Fixing it would mean:
      * re-thinking the UI to be simpler;
      * integrating update-manager’s functionality;
      * properly separating the UI and the APT backend.
So that would mean, basically, redeveloping PackageKit. 

I don’t understand why PackageKit wouldn’t be suitable to replace it. If
it can search packages, install and remove them, upgrade packages or the
distribution as a whole, there is no reason why it couldn’t do the job.

> > > You will be at FosDem?
> > 
> > Nope, sorry.
> 
> I am, and giving a presentation on PackageKit. All welcome for beers
> after, but mention debconf and you'll be buying a round. :-)

I don’t drink beer anyway, but if you come around Lyon I’ll be happy to
share a bottle of wine with you ;)

-- 
 .''`.
: :' :      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/20080220/e164894b/attachment-0004.pgp>