packagekit backend for pkgng
Short description: My proposal is to develop, test and document a PackageKit backend for pkgng, ideally with the view of being able to use an existing PackageKit frontend such as Apper to install, remove and upgrade packages on a FreeBSD system.
- Project Title:
- packagekit backend for pkgng
- Matt Windsor
- 07922 904793
- irc.freenode.net, usually as "hayashi"
- Languages (spoken and written):
- I will probably be taking a family holiday at the start of August for one week (probably the end of the midterm review deadline, so I would be looking to submit my review ASAP); otherwise I can't forsee any other commitments during the GSoC period.
I'm a third-year computer science student with knowledge of C and have been using FreeBSD for about two years primarily as part of my role in the Computing Team at University Radio York where our main Web server and development system run it. I also have some experience in using FreeBSD as a desktop system. Prior to using FreeBSD I have used Linux-based operating systems for a number of years.
For this project I would need to make myself more familiar with pkgng; I've used it a few times during system administration at URY (where we use a combination of pkgng and poudriere to build ports with custom options for the URY systems that use FreeBSD), but have not yet made any advanced usage of it.
(Update: 2012-05-03@11:25UTC: I have no prior background in committing to existing open-source software projects (though have made some open-source releases of my own, mainly from my work with URY and generally not as part of a team), but am keen to get involved and think that GSoC would be a great first step for me. I am willing to learn the processes behind open-source development and look forward to the opportunity to join new communities and hopefully give something back to them.)
Potentially Baptiste Daroussin (bapt), but he mentioned that he would likely be mentoring another pkgng project for GSoC; he mentioned some other names, but I haven't been in contact with them outside of #pkgng.
My proposal is to develop, test and document a PackageKit backend for pkgng, ideally with the view of being able to use an existing PackageKit frontend such as Apper to install, remove and upgrade packages on a FreeBSD system.
(Update 2013-05-03@10:02UTC: To clarify, the PackageKit backend will be written in C against the PackageKit and libpkg APIs and glib, and the deliverable will be a .so file that can be used by PackageKit as a backend as well as the source code to compile it.
PackageKit is GPLv2, so I understand the backend would also be GPLv2 and not FreeBSD Licence.
I would be using clang mainly in development if possible, but intend to write standard C89 or C99, and test compilation with GCC.)
This would make system administration using binary packages easier in these use cases:
- Situations where multiple systems running different operating systems need to be updated by the same people; for example, University Radio York runs both Debian and FreeBSD systems which could theoretically both be served by packagekit if a pkgng backend is created.
- Users who wish to install binary packages on FreeBSD, but would prefer to use a graphical user interface;
- Users who wish to install binary packages on FreeBSD and already know packagekit from an existing supported package manager.
There is an existing packagekit backend for FreeBSD Ports; ideally I would like to implement as much of the functionality already present in that backend as is applicable to pkgng. However, the core functionality (to use the feature matrix headers, GetDepends, GetDetails, GetUpdates, InstallPackages, RefreshCache, RemovePackages, SearchGroup, SearchName and UpdatePackages) would be the main focus of at least the first leg of the project.
- A PackageKit backend that has tested support for basic package installing, removing and updating (the feature matrix features GetDepends, GetUpdates, InstallPackages, RefreshCache, RemovePackages, UpdatePackages);
- If possible, support or substantial progress towards support for SearchGroup, SearchName and GetDetails (otherwise these will be implemented post-midterm);
- If necessary, an updated FreeBSD port of PackageKit as the current one is of a version noted by the PackageKit website as "obsolete" (Update 2013-05-03@10:48UTC: 'kwm' on the pkgkit IRC channel mentioned the possibility of updating this port, thanks!);
- Constant releases on an at least weekly basis of experimental source code and instructions for building for use with the version of PackageKit available for FreeBSD.
- A fully tested PackageKit backend that provides all functionality currently ascribed to the "ports" backend with the exception of any functionality not implemented or applicable for pkgng;
- Documentation from both user and developer perspectives explaining what PackageKit is, how to obtain it, how to use it with pkgng (including with GUIs) and how to further develop it;
- Ensurance via static code analysis tools and peer review that all submitted code conforms to style(9) and best practices, and is ready for extension to support any features unimplemented by the end of the project.
Every feature will require functionality/black box testing; I would investigate the use of jails, virtual machine snapshots etc. (or, where possible, scripted interactions) in order to be able to perform repeatable and fast user-level checking of functionality.
Another possible testing strategy would be to investigate performance of both standard `pkg` calls and their `pkcon`/packagekit equivalents and ensure that the overhead is within acceptable limits (possibly comparing with overhead on existing backends, for example Debian apt).
Ideally I would also like to perform unit testing and static analysis within my submitted code, as well as compile with all warnings enabled. At this stage I'm not entirely sure of the best approach for white-box testing but this would be considered. The fact that the code is in C may be a limit on this (I have no experience with C unit-testing frameworks, a small amount of experience with clang static analyser, and some experience with valgrind).
(Update 2013-05-03@11:04UTC) Timing estimate
In response to a comment on the proposal, here is a (very loose) estimate of what I think the time breakdown of working on the core functionality will be (this is mainly based on reading existing backend code, mainly for oPkg which is what I'm using as a reference for bringing up the basic backend):
- Community bonding period: Familiarising self with glib, the PackageKit API and libpkg; setting up a FreeBSD system to test work; setting up a repository (github or otherwise at mentor's/community's preference).
- Week one (June 17): pk_backend boilerplate, mapping PackageKit package IDs to libpkg names, ideally some way of testing this (which probably entails implementing package description). By the end of week 1 the backend should be compiling and presenting a (very empty) feature set to packagekit, and this will be tested using pkcon.
- Week two (June 24): package description implemented and contingency (as week 1 may be the first foray into actually programming against the APIs, I imagine it'll take longer to "get right")
- Week three (July 1): local package installation
- Week four (July 8): package removal
- Week five (July 15): contacting external repositories, package database updating
- Week six (July 22): package updating and remote package installation
- Week seven (29): Contingency and mid-term evaluation; I'll probably be going away on family holiday this week, but will try to do some off-Internet work (documentation and testing?)
I'm hoping that by the mid-term review there will be at least a rough implementation of the above functionality, with a view to refining it and adding in package search and advanced features during the next few weeks, as well as doing some brief use case testing (GUI package installation and making sure all commands work the same way as they would on eg. Debian). This might be a bit too ambitious, though!