Re: "dselect" replacement team
On Sun, 13 Apr 1997, Ian Jackson wrote:
> I thought the plan was to produce a new user interface for dselect ?
> I see a lot of talk about how dpkg's on-disk data structure should be
> changed - in particular, plans to change /var/lib/dpkg/status
This is the plan. I suggested that we should write all of our lowlevel
manipulation routines in a such a way that they could be the basis for a
general libdpkg. The logical conclusion to something like that is that all
the functions of dpkg should end up in there and then dpkg, dselect (in
all it's incantations) can rely on a single common code base. This
naturally makes fixing/changing/adding things easier as there is 1 place
to change the code.
Weather things will go that far is totaly undetermined yet and is not part
of the project's scope. We will write things so we can make the decision
later on. Many people agree that a general, usefull, documentated library
is a good thing to have.
I also have noticed that you have a lib directory which contains at least
some of the functions, but still an awefull lot of code is not in that
library.
> somehow. I think that these plans are very ill-advised, and that
> anyone who thinks we should change /var/lib/dpkg/status to be a binary
> file should
These ideas were discussed between me and Tom, and revolved around why
dpkg was so slow doing alot of operations, we made some speculations, but
as you say without any benchmarking and profiling we can't make any
firm statements.
> IMO the only change requred for the user interface improvements to
> code which is part of dpkg is to have the dependency checking code as
> a function in the libdpkg section, rather than several varying
> implementations throughout the code. This change can only be made by
> a C expert with a very good understanding of dpkg's internals and
> specification. Apart from that, no changes to dpkg should be
> required.
I think we will either opt to not alter dpkg in any major way and do our
own dependancy handling, or to not use dpkg at all. I am in favour of the
first option.
Someone has hacked a dependancy ordering scheme into dpkg, using a command
line option called --predep-package. That combined with an external perl
script appears to give a level of ordering to the package installation.
> dselect should continue to call dpkg to get dpkg to do the actual
> installastion and removal; this way dpkg can continue to ensure that
> the system doesn't get hosed and mistakes in dselect are less
> important.
Agreed, at least for now. Naturally if the libdpkg idea goes to completion
this will not be necessary.
I look forward to talking with you in May, hopefully we can work together
to create a libdpkg..
Good Luck,
Jason
Reply to: