Date: Sun, 7 Jul 2013 05:15:26 +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 3 Message-ID: <alpine.BSF.2.00.1307070452090.2244@cavalier> In-Reply-To: <alpine.BSF.2.00.1306301724190.1671@cavalier> References: <alpine.BSF.2.00.1306301724190.1671@cavalier>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi all,
Another week, another soc-status mail!
This week I've mainly been implementing basic forms of the InstallPackages
(remote installation) and InstallFiles (local installation) features. The
good news is that I've managed to install (trivial) packages with both, so
they are mostly functional.
There are a few issues to iron out, most notably perhaps being the fact
that I implemented events on InstallPackages a bit too overzealously and
it now bombs out with a fatal error if mild things such as cached packages
having checksum mismatches occur. More cosmetic problems include the
install queues being unsorted (and thus causing a large amount of "these
packages are to be installed, ...reinstalled, ...installed, ...updated,
...installed" noise).
I also implemented a very basic test, mostly for me at this stage, to
check to see if GetDetails gets broken by any changes (and there have been
lots of infrastructure changes). Currently it is pointing out that while
`pkg` can return multiple packages for an unversioned package query, the
backend only returns the first one - I'm not sure as of yet how to proceed
to resolve this.
There are now two main "helper" subsystems available for the common tasks
of selecting one package matching a PackageID and either sending the
package to a function for emitting data from it (GetDetails, GetFiles) or
adding it to a (currently one package only) job and sending it to a
function for solving and applying (InstallPackages). There are a lot of
optimisations and tweaks that could be made to the query functions, as the
whole query code has mostly evolved to save duplication rather than being
designed.
I've also removed most of the dummy boilerplate. I was keeping this in to
remind me which features I needed to install, but as the backend is
becoming more and more useful I thought I'd take it out so no non-GSoC
code is polluting the main code file.
In all, I thought I was going to be behind my milestones this week, but
aside from some niggles left to solve later it seems that both local and
remote package installation are present and informally tested to work in
certain use cases.
Known bugs:
- Backend sometimes crashes when moving from SimulateInstallPackages to
InstallPackages or cancelling; not sure what's causing this at the
moment, will investigate later.
- Test for GetDetails expects certain packages to be installed and
fails when multiple versions of a single package exist, needs some
thought as to how the backend should solve multiple version problems.
- Install list produces multiple reinstall/install/update category
headings due to no sort being produced on the iterator output; may
fix, may leave as-is.
- Non-severe errors can cause the installation to fail with a fatal
error, I need to change the install event handler to stop this.
- All package arguments must be given as PackageIDs; this is due to
Resolve not being implemented, may work on this next week.
~ Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1307070452090.2244>