Re: KPkgManager

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 23 March 2004 17:40, Sylvain Joyeux wrote:
> As the kio-apt and kpkgmanager author, I definitely think I should answer
> to this one :p
>
> > 1) there is a kded module doing the "dirty work" - i particularly don't
> > like this, as it introduces a whole slew of issues... we can probably
> > discuss the details later
>
> It does not use the kded module as a backend. The KDED module is used to
> launch kpkgmanagerd, which is a standalone program, as root.
> The only issue in this design, IMO, is the security issue. Can you point me
> to other ones ?
> What do we gain in this ? The UI does only that - user interface. Building
> other UI is very simple and you can have multiple UI at the same time
> watching over the same daemon.
> On the other hand, supporting another package manager (say, urpmi), need
> only rewriting the backend. Everything else is the same.
>
> > 2) It seems that it uses kio-apt as a backend. It is a design decision i
> > don't agree with completely. I get the feeling that it should use
> > kio-apt for installation as well, which has some issues as well (most of
> > which are shared with point 1).
>
> No, it does not. kio-apt and kpkgmanager are two totally different things.
> kpkgmanager uses libapt-pkg through a library wrapper, libkdeapt, and dpkg
> but nothing else, while kio-apt uses apt-cache directly.
>
> libkdeapt is the library doing the real work. kpkgmanagerd is only a DCOP
> wrapper around it.
Ok, i like  this a lot more. I was confused by this TODO item:
+ install in kio-apt
I falsely assumed that you are using kio-apt to install packages from your 
daemon. Now about the daemon issues. First of all, the security issue, which 
is going to be quite hard to fix.
Other problems i can think of from top of my head:
Take for example backend crashing, leaving frontend in undefined state...
I'm not sure how you manage caches for example. I just looked up the code 
briefly, but i couldn't see eg a package browser. This is kind of thing that 
i guess is going to be problematic. Synchronizing block of 11K package 
records between processes is going to  be pain in the neck. Take simple 
feature likke this: show status for every package in the browser. If frontend 
is dumb, you have to send user actions to backend (which would have to be 
persistent in this case) and get list of generated changes back. Also, you 
would have to transfer whole list of packages at least once and store it 
twice. However, if it is going to be as simple as not providing package 
browser, then it is more or less ok to leave it splitted. But then, i can't 
imagine what differences would be among different frontends, such that one 
would want to run more than one at once (at which point, you could as well 
link to libkdeapt directly and leave out the wrapping daemon and IPC).
>
> As for the package management independence. If you want to port it to other
> systems, you only have to reimplement the DCOP interface (which is very
> simple). kpkgmanager will need no change at all.
Well, i'll describe what libcapture is doing in more detail. It provides a 
priority based approach to package selection, so that user can select what 
and how much he wants. Then, the system will compute what needs to be 
installed. May there arise a conflict, system will decide to install the 
package  with higher priority. This may get quite a bit more complicated, but 
point is that user not only select what he wants (and what he doesn't want) 
but the priority as well. I can hardly imagine how would unmodified frontend 
handle the priority input, for example. Not to say selecting that package is 
explicitly not wanted. And if you only provide an editbox that accept some 
arcane commandline syntax, then it's not exactly what i call "packaging 
system independent".
>
> > As for the "fix KDE/Debconf" item on your TODO: could you please
> > elaborate? I am the KDE Debconf frontend author and i'll be glad to help
> > fixing it if i've broken something :).
>
> It's sent to the debian bts. The bug is that the debconf frontend shows a
> mainwindow even if none is needed, which is quite annoying.
As for the bug, i'll look into it before this weekend  (i can't today (it's 
already late) or tomorrow as i'm out of town). I guess your solution is ok, 
but i'll check just for sure. I guess i should subscribe to debconf pts :).
>
> I wasn't aware of the existence of your project until very recently. I
> definitely think we should see if we can work together.
Yes, that is why i started this dialogue. I surely could use some help. I 
already contemplated about "borrowing" your progress dialog :). The one i 
currently use is borrowed from kmail, the imap sync dialog :)). If you'd like 
to take a look at my code, feel free to check it out from kde's cvs from 
kdenonbeta/kdedebian/kapture. Now, i'm not completely sure how would our 
projects and different views work together, but explaining our points is a 
good start :). I believe it shouldn't be hard to reuse parts of your code in  
my project, but other way is more problematic, as my libraries assume that 
they run in one address space and share data accordingly. There is for 
exapmle only one package cache, that is displayed by the frontend code more 
or less directly and manipulated by the backend at the "same time", using 
callbacks to synchronize. I can hardly imagine how would this be ported over 
to multi-process architecture...
>
> OK, I'm now on the kde-debian ML, so please answer here.
> Best regards,

Yours,
    Peter

- -- 
Peter Rockai (mornfall), mornfall()logisys!dyndns!org, mornfall.homeip.net
- ---------------------------------------------------------------------------
He says gods like to see an atheist around. Gives them something to aim at.
                       -- (Terry Pratchett, Small Gods)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAYIJ3vQmfopLcAqkRAg3ZAJ0fOnCwditb5BlHwUDyOd9ugUgzzACcCKSZ
3vV6e2cL9QyfhmwYoPxr5KY=
=hHS9
-----END PGP SIGNATURE-----