Date: Sun, 21 Jul 2013 23:58:45 +0100 (BST) From: Matt Windsor <mbw500@york.ac.uk> To: soc-status@freebsd.org Cc: jmuniz@freebsd.org, eadler@freebsd.org Subject: GSoC status - Week 5 Message-ID: <alpine.BSF.2.00.1307212107090.1642@cavalier> In-Reply-To: <alpine.BSF.2.00.1307141730330.2244@cavalier> References: <alpine.BSF.2.00.1306301724190.1671@cavalier> <alpine.BSF.2.00.1307070452090.2244@cavalier> <alpine.BSF.2.00.1307141730330.2244@cavalier>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1307212107090.1642>