Re: "dselect" replacement team
On Fri, 11 Apr 1997, Martin Schulze wrote:
> > I would think it would be a bit more general than "a clone of dselect with
> > different keys and colours" - a complete re-implementation of the
> > packaging system so that the user interface is distinctly separate from
> > the underly mechanisms, which are distinctly separate from the low-level
> > access code would be very nice.
>
> Much has to be done... I'm in the process of creating a list of them...
I'd be interested in this list when you get done..
As for Tom's comments.. I was trying to be very general with that
statement, people seem to like most of what dselect does, one previous
poster commented that we souldn't replace it, mearly alter. So in a sense
the end result from the users point of view will be much like I described.
The source code however is the real challenge, alot of people want a
dselect/dpkg library they can use in their own code, which is of course
what Tom is speaking about.
> > Berkeley libdb, for example), to make things easier. As someone said
> > earlier, reimplementing the "dpkg" utility itself to be an extra frontend,
> > rather than a backend to the interface, would fit especially well into
> > this case.
>
> I object. I don't think you can easily correct the status file after
> a failure with "vi /var/lib/dpkg/status" if it is not a plain ascii
> file. This is a feature which I have needed several times - and normally
> I am careful with my systems...
Can you describe what happened in a few of these situations? AFIK it
should never happen the you have to actually modify the status file.
Anyhow, after we get our libdpkg going we can do some benchmarks and see
how fast text file parsing is. I ran some tests last night on my 486, you
can read the entire avalible list line by line in .46-.78s if it's in the
disk cache. (17k lines of text, 600k). So any lag is caused by the actual
filesize or a slow parser.
Libdb might be a good idea to implement in a cache mode, ie have status.db
which is a mirror of status in libdb format, then if status is changed the
db is rebuilt.
> > * Can be built as non-root
> Which includes an own tar creater - and the tar extractor has to
> be extended, too. It cannot handle long filenames...
Bruce mentioned that gnu tar will contain some features to allow this in a
newer version.
Jason
Reply to: