[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: KDE/Qt Package Manager (Re: Google Summer of Code 2009: Debian's Shortlist)



On 2009-04-11, Filipus Klutiero <chealer@gmail.com> wrote:
> Obey Arthur Liu wrote:
>> * KDE/Qt4 Adept 3.0 Package Manager *
>> -------------------------------------
>> Student: Mateusz Marek, Mentor: *NEEDS MENTOR, see below.*
>>
>>     Finish Adept 3.0, a fully integrated package manager for Qt4/KDE4.
>> Adept is currently the only viable path to a Debian native package
>> manager on KDE that would support modern features such as tags, indexed
>> search or good conflict resolving. With Aptitude-gtk still in
>> development and only available for GTK+ and (K)PackageKit having
>> fundamental problems, Debian needs this project to stay in control of
>> its package management on KDE after much neglect in the recent years.
>>   
> At the risk of repeating myself, what are the fundamental problems in 
> (K)PackageKit?
>
> I have no issue with Adept, and I would love to see a good Qt/KDE 
> package manager, but if we're to get KPackageKit, I'd like to be sure 
> that we won't sponsor yet another APT front-end that won't be used.

As far as I understood it,

PackageKit has no back and forth communication with the user about what
to (not) install.

You can tell packagekit to install/remove a package, but unless you
implement full dependency resolution in the packagekit frontend, you
can't properly figure out what to (not) do.
And if dependency resolution is to happen in the frontend as well, then
packagekit lost all it's theoretical advantages.

Beside that, it answers 'no' to all dpkg conffile prompts, and interaction
with debconf looks like more a hack than a real solution.

Oh. and then, packagekit is made to give users the ability to install a
few packages on their own, not to do full package administration.

/Sune


Reply to: