File:  [NetBSD Developer Wiki] / wikisrc / projects / project / Attic / pkgsrc_packagekit.mdwn
Revision 1.1: download - view: text, annotated - select for diffs
Sun Nov 6 01:59:12 2011 UTC (6 years, 5 months ago) by jmmv
Branches: MAIN
CVS tags: HEAD
Move existing project definitions from projects/gsoc_2011/ to
projects/project/ .

The goal for this reorganization is to remove any knowledge of the projects
classification from the file hierarchy: the classification goes into tags,
and projects indexes automatically list projects based on such tags.

Also, the current gsoc_2011 name was wrong anyway, because GSoC 2011 has
already concluded and projects would have had to move to a gsoc_2012 directory

Lastly, yes, "projects/project/*" is slightly redundant.  But I want to keep
the project lists from the projects "database" clearly separated.

This is as proposed in www@.

[[!template id=project

title="Add pkgsrc support to packagekit"


[Thomas Klausner](, [Emile 'iMil' Heitor](

duration="3 months"

Add pkgsrc support to [packagekit]( so the graphical packaging software "just works" for pkgsrc

The pkgsrc/pkgtools/packagekit package currently contains a minimal implementation of pkgsrc support to get the package to compile.
This should be extended.

Useful steps:

* Show all installed packages and let the user delete them
* Show list of available packages (local/remote) and let the user add them
* Show lists of available updates
* Include security information, i.e. show recommended updates based on audit-packages and list of installed / available packages

Additional goals:

* Show progress and / or console while installing / upgrading
* pkgsrc's PackageKit backend is to be integrated upstream (PackageKit people are open to contributions, that won't be an issue)
* It must not be mandatory to install the pkgsrc source tree (binary packages-only needs to work)
* If installation / upgrade hits a package not available as a binary (typically packages where the license doesn't allow distribution in binary form, e.g. flash, mplayer-share, ...), try to fallback to the pkgsrc source tree if it is available and explain causes and consequences to the user. That could be part of pkgin instead of the PackageKit backend.
* In case of failure, the full log shall be displayed so that the user has a chance to fix the problem "by hand". Some explanations about the failure would be nice. A useful log is mandatory in order to be able to request help from the pkgsrc-users mailing list or to open a PR.
* Using a convenient programming language, the student shall write an abstraction layer / API, permitting to easily manipulate pkgsrc.

    This layer shall permit to :

    * Return pkgsrc version
    * Return an installed package list/map
    * Return a "to-upgrade" package list/map
    * Return a full "package map" (non-automatic + dependencies)
    * Return an available package list
    * Install/upgrade/remove a new package and its dependencies
    * Return information about a package (DESCR, version, PLIST, Makefile, options, ...)
    * Display security information

[[!tag gsoc]]
[[!tag medium]]
[[!tag pkgsrc]]

CVSweb for NetBSD wikisrc <> software: FreeBSD-CVSweb