Re: [GsoC] Add pkgsrc support to packagekit

[Julio Merino <jmmv%NetBSD.org@localhost>]

On Sun, Mar 27, 2011 at 2:45 PM, Sylvain Mora
<sylvain.mora%googlemail.com@localhost> wrote:
> Hello,

Hello Sylvain,

Thanks for taking the time to write this proposal.  A few comments inline.

> I'm Sylvain a french student in Computer Sciences of "Université de Pau et 
> des Pays de l'Adour" (UPPA). I discovered NetBSD more than 1 year ago, and 
> this year I want to contribute to the project through the Google Summer Of 
> Code.
>
> I use NetBSD on my desktop (but I use it less often than my laptop), my 
> Sheevaplug and plan to use on a dedicated server as soon as possible. Thanks 
> to IRC I have learnt lot of things about NetBSD.
>
> I'm currently working on writing a pkgin backend for PackageKit, so I'm 
> really interested in the "Add pkgsrc support to packagekit" project.
> My goal is to write a Python API for Pkgin to make the writing of the backend 
> easier.

My main question in your proposal is: why Python?

Having an API to interact with pkgsrc and binary packages would be
wonderful.  Unfortunately, Python is not part of NetBSD.  If you write
the library in Python, it means that we cannot use it in the places
where we need it most: in sysinst or in pkg_install so that an
out-of-the-box NetBSD installation could easily retrieve/install new
packages and keep the system up to date.

Having said that, a Python API would work nicely as a prototype.  But
you should investigate how this would play with the languages that are
part of NetBSD (C, C++, shell and Lua).

> Reading the Wiki I think I can make the same work with pkgsrc :
> - Write an API for pkgsrc
> - Use this API to write a backend
>
> It may be possible to reuse part of the pkgin API for binary package 
> management (or rewrite something equivalent for pkg_add).
>
> The API will reproduce basics pkgin/pkg_add/pkgsrc commands and add useful 
> methods like listing all outdated packages, listing installed packages in 
> which package names, versions, etc are separate.

In my opinion, the library should seamlessly manage packages from
pkgsrc and binary packages (this is quite tricky but certainly
doable).  An example: install/update everything from binaries if they
are up-to-date, or otherwise fall back to building from pkgsrc.
Nixpkgs (http://nixos.org/nixpkgs/) does this successfully and the
results are very handy.

> The harder part will be the capability to build package from source because I 
> have to reproduce what did "make" in Python for retrieving dependencies etc 
> (The backend allows to make package if it is not available as binary)

For this, you can just resort to calling make and parsing the results;
this is slow but effective.  Alternatively, if the "summary" database
exists, just parse that database to get much faster results; see
pkg_summary(5).

Lastly, I'd recommend to extend your proposal a bit more by including
a list of deliverables, a preliminary schedule with a set of major
milestones, and more examples on how your proposed API would look
like.

Hope this helps!

-- 
Julio Merino / @jmmv