Namcap 2.8 release and future plans
On Sun, Jan 30, 2011 at 2:40 PM, Rémy Oudompheng <email@example.com> wrote:
> I would like to release namcap 2.8 : it contains several new rules, and
> several bug fixes.
> * the git repo : http://projects.archlinux.org/users/remy/namcap.git/
You should push all of this to the main repo since it is official, as
far as I am concerned.
> * the source tarball : http://dev.archlinux.org/~remy/namcap-2.8.tar.gz
> * the package : http://dev.archlinux.org/~remy/namcap-2.8-1-any.pkg.tar.xz
And feel free to push this to the repos (probably [testing] first) and
adopt the package.
> A notable addition here is the appearance of a test suite.
> Feel free to make any comments.
> I don't think I'll do many fixes on the 2.x branch.
> My plans for namcap 3 :
> * use Python 3
> * parse split packages : PKGBUILDs are parsed in a "pkginfo" structure,
> *I'd like to parse split packages into a tuple
> * *(pkgbase, list of pkginfo's),
> *does this look ok to you ?
> * use a class hierarchy for rules :
> * *AbstractRule : defines very basic functions (get_name, get_description)
> * *PkgBuildRule, PkgInfoRule, TarballRule : derived classes applying
> * * *to a PKGBUILD, to only one package in a split PKGBUILD, to a
> * * *tarball
PkgbuildRule would probably be a bit more fitting for case; I've never
seen anyone call it a PkgBuild before. But that is a nitpick, and this
organization makes a lot more sense than the current method-based
> *this allows putting many rules in a single file and loading them using
> *calls to isinstance() or issubclass() functions.
> * optionally : implement dan's idea of turning rules into callbacks.
> *I have doubts about the benefit of such a transformation, but several
> *of our tarballs are quite big and such an optimisation would be
This would be the beauty of moving to subclasses- once converted,
extracting the per-item functionality into an instance method could be
done, and then eventually remove the looping from the TarballRule rule
> Such a callback would be implemented in the following way : define an
> generator/coroutine that yields files in a tarball (it would be useful
> to read raw tar.xz tarballs, for example by reading the pipe out of an xz
> Then the main loop of namcap iterates over this generator and feeds files
> to all relevant rules (TarballRule calass), which should implement a
> method called e.g. read_file().
> The rules should gather information about the tarball in one pass.
> Then call some method called post_process? analyze? finalize? for all
> these rules: in this method, the rules use all the gathered information,
> e.g. the output of readelf -d, to compute the result and return it.
Sounds feasible, at least.