Re: KPkgManager

On Wed, Mar 24, 2004 at 12:30:58AM +0100, Sylvain Joyeux wrote:
> > 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.
> I'm not so sure, but I only have ideas from now. I'll have to discuss the 
> security issue with the kdelibs & dcop guys.

Ok, i guess we can leave this alone. But i'm still convinced securing the
communication is going to be pain. And 15 seconds is a hell lot to
perform timing attacks...

> 
> In fact, the KDED daemon is here for that too - being the third man which 
> gives control (or not) to kpkgmanagerd.
> 
> > Other problems i can think of from top of my head:
> > Take for example backend crashing, leaving frontend in undefined
> > state... 
> The DCOP server tells us when somebody deregisters from it, and (moreover) 
> the KDED module watches the kpkgmanagerd process and tells the frontend 
> when it dies. It works pretty well (at least, I
> 
> > 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. 
> I don't WANT a package browser here. I want a package MANAGER. It's the 
> thing I don't like in most of the graphical package management tools, they 
> are bloated because of this (IMO useless) package browser. Kio-apt is the 
> package browser, kpkgmanager the package manager.

Now, i must disagree. If you never wanted to browse packages that are
going to be upgraded, then well, your luck. But at least i really miss
things like browsing and (especially) searching upgrade list. Things
like slapd on which my system relies need special care when upgrading,
so i want to be aware of them. Grepping upgrade list visually is a pain
in the neck.  Another thing: why would i want to use your frontend? I
can as well launch console and use apt-cache and apt-get, with about the
same comfort and speed as kio-apt with kpkgmanager. If i look for
something nonspecific, i'll have to launch aptitude in both cases...  As
for the browser: the browser implemented in libcapture (ie, the backend
part of it) is quite flexible. It provides everything apt-cache does,
but installation and "management" is only a click away. Stumbled upon
package you want? Check a checkbox and you are done. Are you curious
what changes to system will be done? Select "changed" [*] filter in
browser and look at packages that will change their state. There are
many things browser gives you, even if you don't use it in the
"straightforward" way. And apt-cache like program or kio is a snap: just
load libcapture, let it build the filters, get the resulting tree and
format it as you like.

[*] - Not yet implemented, but not very hard to and definitely planned.
Needed anyway, as the change lister will be a custom browser instance.

> 
> > 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, I can assume you're reimplementing apt, at least to a certain extent 
> (what I definitely don't want to do)

Well, not exactly. The libcapture is a wrapper that makes it easy to
write frontends: browsers, (cli) (de)installers, etc. It should make it
possible to work in netwrok-transparent fashion (asuming the machines
have same cache), or even exhibit the kind of "multi-process"
architecture you describe using a daemon (read-write) and clients (read
only) sending user input to the backend (both link to same library, so
results they get should be same). But then, i'm still not convinced of
benefits of such architecture. In other words, what this architecture
gives me that i can't have in one process?

> 
> > 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. 
> Priority input ? libapt-pkg uses package pinning, and making a frontend for 
> it is not so difficult. Plugins are here to handle such special cases.

Well, frontend for pinning needs a package browser or something
equivalent first. Setting pins by name is about as comfortable as doing
it with text editor. I mean: if you want to pin all the X packages, you
are going to type a hell lot... And user interface that will respect
user changes to /etc/apt/preferences is not that easy (the other options,
monopolizing or breaking upon changes) is not exactly the debian way. If
you figure some nice interface though, i'll be glad to use it for
libkapture and libcapture. The presentation specific part would be for
libkapture and parser, writer and stuff like that (the backend) for
libcapture...

> 
> I don't want to provide the package management mechanism. It's up to the 
> package managers (apt, urpmi, ...) to provide that. I do only an interface 
> to them. It is definitely enough work before having The Good Tool.

Well, the AMAS system to compute the dynamic preferences is now almost
complete. I will be hopefully able to focus on more fundamental stuff
again soon, like PackageManager interface (that wouldn't be as broken as
current libapt/dpkg interface is) and finally fixing the progress
dialog. Other than that, there is little that remains to get it "usable"
(ie, capable of doing routine package management). Things like pinning,
more advanced debtags support, package groups (like in fedora installer)
and user friendly profile (view) are on TODO. More details in
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdenonbeta/kdedebian/kapture/TODO?rev=1.13&content-type=text/x-cvsweb-markup

> 
> I think I can (easily) use libcapture in kpkgmanagerd, but I definitely 
> don't think we have the same goals for the GUI (but the discussion would 
> be a good thing too).
Well, i suppose so. I would be more than glad to talk with you on IRC or
some IM (i have jabber and ICQ accounts). Somehow, i don't like these
mailing list debates, as they tend to look like flamewars :)). Also, if
you feel like i attack you, that's actually not the case (even if i
sound like that). I feel kind of guilty for opposing you, so let me
reassure you i appreciate what you do and whether we join our efforts or
not, i'd be happy to cooperate and if nothing else, exchange ideas and
possibly share code.

> -- 
> Sylvain Joyeux

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)