Re: "dselect" replacement team
On Apr 11, Jason Gunthorpe wrote
> > 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..
If no one stops me it'll be placed in the doc directory on our ftp
server.
> > 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.
One day I read a new package.gz and got epoch which my dpkg didn't
understand. There was no time for long reading of dpkg's manuals
to the best way was, vi status available; dpkg -i dpkg_<new release>.deb
One other day the whole /var/lib/dpkg directory got munched, dunno
why.
> 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.
Sure, a binary format would be faster. But I don't think that it would
be that fast that we should lose our ascii files. Just believe the only
file for debian which is not plain ascii is .deb.
All other files like debian/rules, debian/control, configuration files
etc. etc. are plain ascii files. I have a very strong feeling for
keeping them.
> 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.
Hmm, I have a very simple idea.
libdpkg looks for status and status.db. If the latter exist and has the
same date or newer it is taken, otherwise the plain ascii file is used
and a new .db is generated. What about this?
> > > * 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.
Fine, which doesn't matter as Bruce wrote the tar extracter in
dpkg-deb which is unusable for long filenames. (I ran into this once
I tried to package Spinner - and gave up...)
Regards,
Joey
--
Individual Network e.V. _/ OrgaTech KG i.Gr.
joey@office.individual.net _/ joey@orgatech.de
Geschaeftszeit: Di+Mi+Fr, 15-18 Uhr _/ Tel: (0441) 9808556
Reply to: