[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Lintian as a static analysis framework



On 2011-07-07 18:24, Stefano Zacchiroli wrote:
> On Thu, Jul 07, 2011 at 12:00:38PM +0200, Niels Thykier wrote:
>> [...]
> 
> To achieve the above two goals, I need to keep in sync a Debian (source)
> mirror with a place where I've all sources unpacked in versioned
> directories. Additions/removals to the mirror should be reflected to the
> unpacked source storage. I'd also like to be flexible in adding/removing
> suites and archive areas to the source mirror, as well as be easily able
> to re-extract everything from source. So much for the extraction part.
> 

So basically incrementally pulling packages from a mirror via Sources
file? I cannot help but think we must do something like that on
lintian.d.o (especially considering we usually do incremental runs).

> Then I need an easy way to access all (unpacked) source packages I have,
> query their package metadata, find their root directory and run my
> analysis tool of choice on the source package.
> 

Bulk access or a "given package name (possibly + version and arch) give
me the rest of the metadata and the root dir of the unpacked package"?

> Finally there is also a database part, where I'd like to storage the
> result of the analysis tool and keep all the history of it.
> 

Here we just dump everything to a generic log file on l.d.o as I recall,
so I doubt I can offer you anything better.

> I've ended up cooking up my own code for the above (not all is done
> yet), but there clearly a good part of it that could be factored out
> (and done better). Do you think the framework you're imagining at this
> point could help with any or all of the above?  If yes, I'll be happy to
> provide testing and/or comment on whether the design would fit the need
> of the above use cases.
> 

I think we can do at least the first and most likely also the second.

> FWIW, I believe many other wannabe entrants in DACA would benefit from
> the addressing of similar use cases.
> 

Part of the reason I am suggesting this.  :)

> Thanks for sharing and for thinking about this!
> Cheers.

~Niels


Reply to: