[gentoo-soc] PMS Test Suite, weekly report #10 (midterm sumup)

[gentoo-soc] PMS Test Suite, weekly report #10 (midterm sumup)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3236 bytes --]

Hello, all.

Short summary: PMS Test Suite is a suite of tools and a test library
to test any of the Gentoo Package Managers for compliance against
the Package Manager Specification.

Homepage: http://www.gentoo.org/proj/en/qa/pms/pms-test-suite.xml
gitweb: http://git.overlays.gentoo.org/gitweb/?p=proj/pms-test-suite.git
github (mirror): https://github.com/mgorny/pms-test-suite


Midterm sumup
-------------

Up until now, the core part of the 'PMS Test Suite' project is almost
ready. The suite is now able to run a number of tests for PMS
compliance.

The tests can be run in either 'minimal' or 'comprehensive' mode.
The former one means checking only EAPIs relevant to changes
in the spec, while the latter means checking every EAPI supporting
the particular feature.

PMS Test Suite is able to run tests using portage, paludis and pkgcore.
All basic features including merging is supported for all three PMs.
Portage and Paludis are able to generate Manifests as well. Portage
and pkgcore can be set to run without Manifests. Portage is able to run
with a temporarily appended repository, while the other two require
having the test repository configured.

The development of 'PMS Test Suite' has resulted in two side effects,
maybe even more important than the project itself. First of them is
a number of patches to the PMS spec, making the spec more clear. These
could be found on the gentoo-pms mailing list [1].

The other side effect is the 'gentoopm' project [2,3], providing
an unified API to access all three PMs mentioned earlier. Right now, my
main focus is implementing new interfaces there, and moving the code
out of PMSTS to it.

Right now, gentoopm has already made its first release into the tree,
and became used in smart-live-rebuild [4]. It is already able to find
packages in basic kinds of repositories, get their metadata and read
environment.bz2 files. It can work with atoms too.

I'd like to make it able to construct (and use) PM tool calls for
various operations like installing and uninstall packages. It's going
to use a flexible interface, making it easy to fit into various working
environments -- printing argv, running through subprocess, glib event
loop, threads and so on.

[1]:http://archives.gentoo.org/gentoo-pms/
[2]:https://www.github.com/mgorny/gentoopm/
[3]:http://git.overlays.gentoo.org/gitweb/?p=proj/gentoopm.git
[4]:https://www.github.com/mgorny/smart-live-rebuild/


Last week report
----------------

Changes:
- bash parsing (using BashServer),
- environment.bz2 reading,
- passing atoms as strings to pkgset.filter(),
- accessing userpriv settings from PM config,
- getting atoms for packages,
- atom API - stringification, transformations, associating, accessing
  parts,
- optimizations to PMStackWrapper, portage atom matching,
- dropped a number of redundant properties from PMPackageMetadata.

Plans:
- find the best way to check RDEPEND=DEPEND fallback (as getting
  metadata['RDEPEND'] is harsh for paludis),
- clean up the metadata API in gentoopm,
- release the second version,
- add support for testing eclasses,
- move PM running code into gentoopm.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-soc] PMS Test Suite, weekly report #10 (midterm sumup)

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]

On 13:11 Sun 17 Jul     , Michał Górny wrote:
> The other side effect is the 'gentoopm' project [2,3], providing
> an unified API to access all three PMs mentioned earlier. Right now, my
> main focus is implementing new interfaces there, and moving the code
> out of PMSTS to it.
> 
> Right now, gentoopm has already made its first release into the tree,
> and became used in smart-live-rebuild [4]. It is already able to find
> packages in basic kinds of repositories, get their metadata and read
> environment.bz2 files. It can work with atoms too.
> 
> I'd like to make it able to construct (and use) PM tool calls for
> various operations like installing and uninstall packages. It's going
> to use a flexible interface, making it easy to fit into various working
> environments -- printing argv, running through subprocess, glib event
> loop, threads and so on.

You might be interested in checking out what parts of the portage API 
are used by the Gentoo PackageKit backend, and making sure those are 
supported in gentoopm. Even more interesting would be completing a port 
of the PK backend to gentoopm. This latter part is clearly beyond the 
scope of your project, but it would be really useful after the summer 
ends.

-- 
Thanks,
Donnie

Donnie Berkholz
Admin, Summer of Code
Gentoo Linux and X.Org
Blog: http://dberkholz.com


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-soc] PMS Test Suite, weekly report #10 (midterm sumup)

[Brian Dolbec]

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]

On Sun, 2011-07-17 at 22:43 -0500, Donnie Berkholz wrote:
> On 13:11 Sun 17 Jul     , Michał Górny wrote:
> > The other side effect is the 'gentoopm' project [2,3], providing
> > an unified API to access all three PMs mentioned earlier. Right now, my
> > main focus is implementing new interfaces there, and moving the code
> > out of PMSTS to it.
> > 
> > Right now, gentoopm has already made its first release into the tree,
> > and became used in smart-live-rebuild [4]. It is already able to find
> > packages in basic kinds of repositories, get their metadata and read
> > environment.bz2 files. It can work with atoms too.
> > 
> > I'd like to make it able to construct (and use) PM tool calls for
> > various operations like installing and uninstall packages. It's going
> > to use a flexible interface, making it easy to fit into various working
> > environments -- printing argv, running through subprocess, glib event
> > loop, threads and so on.
> 
> You might be interested in checking out what parts of the portage API 
> are used by the Gentoo PackageKit backend, and making sure those are 
> supported in gentoopm. Even more interesting would be completing a port 
> of the PK backend to gentoopm. This latter part is clearly beyond the 
> scope of your project, but it would be really useful after the summer 
> ends.
> 

Hey, i could use some help in creating the emerge action portion of the
portage public api.  I had been holding off for a bit until the
difference between the portage and pkgcore backends got resolved in
porthole.  I do have an early partial port of the packagekit backend.
Zac has also done a quick review and given some direction for it.

If your up for it, let me know

-- 
Brian Dolbec <brian.dolbec@gmail.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]