GSoC status - Week 5

[Matt Windsor]

Hi there,

Not a lot has happened this week either, to be honest.  I blame myself for 
giving myself very weak targets this halfterm, and hopefully the ones I 
set for next halfterm will be significantly meatier.

I'll start providing soc-svn revision numbers from now on, too, so things 
I say here map down easier to actual code.  Also doubles as a rough idea 
of how much work I've got done in any given week :-)

This week's milestone was done in only three commits (r254912, r254915 and
r254917) in a somewhat minuscule portion of one day; a testament either to 
the ease of use of libpkg or my bad milestone authoring.  This implemented 
RefreshCache, which is a wonderful PackageKit action that does what `pkg` 
does every single remote action (fetches repositories).  I haven't been 
able to test this one aside from running it once and seeing it not crash, 
so I'm not sure how to finish this one off.

r254923 implemented SearchFiles, as usual basic testing via installing and 
running the command happened.  This is a job that can easily be tested via 
comparison to the output of `pkg which`, so making a more principled test 
should be easy and I'll try to get this done next week.

r254997 and 254999 introduced a somewhat untested and barebones version of 
GetUpdateDetail; since GetUpdateDetail allows for a much richer variety of 
details about updates than my knowledge of libpkg allows for, I'll likely 
need to pester people for ideas as to how to map from available data to 
the function call:

 	- Update PackageID (implemented)
 	- PackageID of package updated (implemented)
 	- PackageID of package obsoleted (not sure yet how to do this)
 	- URL to details from vendor about update
 	- Likewise, but from Bugzilla
 	- Likewise, but from related CVEs
 	- The type of restart required (not sure yet how to do this)
 	- Textual reason for update (currently hardcoded as 'new version
 	  available', any ideas for improvements?)
 	- Changelog (no idea)
 	- Update state, eg "stable", "testing", "unstable", etc.  (not
 	  yet)
 	- Date of package issue
 	- Date of last package update

Not much of this wealth of information is yet provided; I'll likely 
revisit this later.

In r255000, a rather grand number for a minor fix, I made the somewhat 
minor fix of having packages be added to jobs using name-version arguments 
rather than just names.  This means that, should a repository have 
multiple versions of a package available, trying to install/remove a 
specific version will now function properly.

The way jobs work is very suboptimal (perform a (r)query, send 
name/version of result into job) and is mainly done this way partly 
because the code for doing the (r)query from a PackageID already existed 
and worked, and partly because this way the architecture of the package 
can be compared easily to the one specified in the PackageID (not sure how 
I'd do this if adding the job directly).  Until I can figure out a 
solution for the latter or direct package queueing for jobs, this is going 
to be an issue.

A rather long email for a rather short amount of work, really.  Next 
week's milestone has already been done in one sense (updating package = 
installing package from remote = InstallPackages = done except for bugs), 
so in the interests of giving myself some actual work to do I'm going to 
promise that I'll work on the following instead:

1) Add assertions to existing code (mainly for null pointers but we'll see
    if anything else needs to be asserted);
2) Write compare-with-pkg tests for SearchName (`pkg search`) and
    SearchFile (`pkg which`);
3) Make anything taking a PackageID fail if the PackageID has a blank
    version;
4) Find out the difference between InstallPackages and UpdatePackages,
    make any changes to InstallPackages (is it allowed to update packages
    itself?) and try to make UpdatePackages.

This leaves a nice amount of more higher-level features to implement in 
the second term, as well as performing testing and boxing the whole thing 
up as a port at the end.

~ Matt