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

Re: apt-show-versions rewrite

(Dropping sprezzos-dev@googlegroups.com, as it is member-only)

On Sun, Mar 10, 2013 at 02:54:34PM +0100, David Kalnischkies wrote:
> On Sun, Mar 10, 2013 at 1:28 PM, nick black <nick.black@sprezzatech.com> wrote:
> > As part of my RAPTORIAL project (https://github.com/dankamongmen/raptorial),
> > I've implemented "rapt-show-versions", an apt-show-versions clone making use
> > of my libraptorial library. This multithreaded C engine ends up being quite
> > a bit faster than apt-show-versions; a single core run comes in around .21s
> > whereas apt-show-versions takes about 1.01s, while allowing it to use all 4
> > hyperthreaded cores drops this to .04s. We will soon begin shipping
> > RAPTORIAL tools in SprezzOS.
> You forgot to provide the source for your rewrite; the "library" is rather
> small to have a serious look at it even through a multithreaded cache would
> be interesting, but it not even builds as I miss a "blossom.h" which apt-file
> couldn't tell me where to find …

It is not even utilise a cache apparently, just like cupt, it's based
on re-parsing files on start up. I am also not convinced that multi-threaded
libraries are a sane idea at all. I appreciate thread-safe libraries, but
libraries that create threads themselves can be hard to control and might
interact with other code parts in unexpected ways.

> > Note that I don't by any means propose replacing other APT components
> > with RAPTORIAL, yet.
> Based on the README the keyword in this sentence is "yet", so:
> Yeah, yet an other project striking to rewrite APT in the future!
> If only half the amount of time used to write all these rewrites would be
> used to help the chronic under-staffed APT team … :(

ACK. It is far too hard to rewrite APT for a normal person anyway; so
even given APT's long development time and the resulting suboptimal
code-base, it is probably easier to modify APT than to rewrite
everything from scratch. And without knowing the internals of APT;
trying to rewrite it does not make sense at all

The only reasonably complete re-implementation of APT is Cupt, so
if people want a cleaner code-base to work on, I suggest that they
start helping there. Although  I do not know how actively it is
developed nowadays, the last update was in August 2012.

Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

Reply to: