Re: KDE/Qt Package Manager (Re: Google Summer of Code 2009: Debian's Shortlist)
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. Still, it remains the aptitude-qt solution. But it seems aptitude code is tighten with the gtk backend and extending it to add the qt backend cannot be done now. Does it make sense to finish Adept3 when it can(should?) be superseeded later by aptitude ? Why not finish aptitude-gtk separation then properly add qt pieces ? please note that I never looked aptitude source code. cheers, Fathi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: KDE/Qt Package Manager (Re: Google Summer of Code 2009: Debian's Shortlist)
Fathi Boudra a écrit : 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. Still, it remains the aptitude-qt solution. But it seems aptitude code is tighten with the gtk backend and extending it to add the qt backend cannot be done now. Does it make sense to finish Adept3 when it can(should?) be superseeded later by aptitude ? aptitude-qt would not be possible before squeeze. That would leave us with no usable Qt4 package manager. Why not finish aptitude-gtk separation then properly add qt pieces ? Another strategy is to replace the adept/ept backend of adept 3.0 with the aptitude backend once it is transformed into a library. It seems to have become some sort of habit for aptitude to explore new features before having them ported back to the common apt code. Cheers Arthur -- Obey Arthur Liu http://www.milliways.fr signature.asc Description: OpenPGP digital signature
KDE/Qt Package Manager (Re: Google Summer of Code 2009: Debian's Shortlist)
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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: KDE/Qt Package Manager (Re: Google Summer of Code 2009: Debian's Shortlist)
On 2009-04-11, Filipus Klutiero chea...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
