[packagekit] Debconf and PackageKit Was Re: Packagekit and Ubuntu

[Daniel Nicoletti]

> I've been intending to give you a more detailed response, but have not
> had time yet. However, on inspection of the code you sent previously, I
> found much the same issues as I explained to you at some length on
> #debian-devel a while back. Joey may feel differently (I don't want to
> put words into his mouth), but I'm afraid my previous comment stands; I
> do not intend to accept any code that creates a completely new UI
> framework for debconf. This approach divides the already scarce effort
> apparently available for writing good-quality debconf UIs (witness the
> fact that nobody's got round to writing a KDE4 UI module yet - your code
> is *only* usable in a PackageKit context, not in general; and
> furthermore we'd have to write substantial new code in order to use the
> same approach with GNOME).

Ok, seems that you didn't get or read or anything my last email :P
I already got the idea where you don't want to have duplicated
frontends, that of course makes sense. Talking with Michael Vogt,
he suggested to do what James wrote in the first email 
(extending passthrough to use DBus).
Actually that isn't of all bad, but it could be simpler than
all the proxing he talked about.

But even simpler would be to
call debconf-comunicate --create-socket=/tmp/debconf_002
and let debconf-comunicate does exactly what aptdaemon
does, listem and write to that socket.

Why this is better than using DBus:
- No new frontend or extending stable code
- Would probably be faster since there wouldn't be the DBus layer

This of course does not give us a KDE4 interface,
since the lack of perl-qt4 still there, but it allow
KPackageKit and Gnome-PackageKit to simply call
debconf-comunicate without worring about sockets
and dbus-connections.

With this small effort would allow any application to support
debconf with just a debconf-comunicate call.

> You've repeatedly mentioned two weeks as a small amount of development
> time; so far it took me two *hours* (while at a conference, surrounded
> by distractions) to get something working, although I still need to
> rearrange it to match what I discussed with James and others, and the
> feedback from Richard. I'm a lot happier with this since it will
> actually be maintainable as we evolve debconf.

Yes sorry for repeatedly saying that, I just said that cause for a debconf
novice it seems to me a very small amount of time.

BTW iirc there is a cmd line tool called kdialog which is pretty much like
dialog, do you think it would be acceptable to use it or even write a new
frontend like the dialog one so we can have a compiled kde4 frontend?
(at least till perl-qt4 get's ready)



      ____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com