FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Pacman Development

 
 
LinkBack Thread Tools
 
Old 01-30-2011, 07:40 PM
Rémy Oudompheng
 
Default Namcap 2.8 release and future plans

Hello,

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/
* 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

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
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
valuable.

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
process).

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.

--
Rémy.
 
Old 01-31-2011, 04:13 PM
Dan McGee
 
Default Namcap 2.8 release and future plans

On Sun, Jan 30, 2011 at 2:40 PM, Rémy Oudompheng <remy@archlinux.org> wrote:
> Hello,
>
> 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
callback thing.

> *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
> *valuable.
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
types altogether.

>
> 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
> process).
>
> 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.

-Dan
 

Thread Tools




All times are GMT. The time now is 10:38 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org