Re: "dselect" replacement team
On 11 Apr 1997, Steve Dunham wrote:
> Jason Gunthorpe <jgg@gpu.srv.ualberta.ca> writes:
> > On Thu, 10 Apr 1997, Peter Iannarelli wrote:
> > The immedite goal seems to be to correct/improve the problems with
> > installation of packages.
>
> Has the sorting problem been fixed yet? We need some sort of remedy
> for this before 1.3 is released. This is one of the issues that keeps
> me from recommending Debian. I helped someone through a 1.2.6 ftp
> install recently and had to do install,configure,install,configure
> (about 5 iterations) because it was trying the packages in the wrong
> order.
That has not been fixed - no code has been written for the new dselect,
but can be fixed so easially. The trouble is that dselect calls dpkg and
tells it to recursively install the packages that are selected, it does.
It needs to pre-sweep the directory tree matching against the selected
list and then depth sort that resulting list, discarding anything that
cannot be installed and then installing in that order.
However dpkg seems to be written in perl, at leas the source from bo has
perl files -- I think they are compiled somehow in the distribution. I
suppose it's hard to do something like that with perl? With the design I
have in mind for the new dselect/dpkg lib it will be a trivial thing.
I do not think a fixed dpkg would be allowed into frozen simply because it
might be too complex a change. If Brian gets the team together and I get
to write the new base then I will try to make a dpkg caller that does
attempt this sorting before the end of April, I have exams though so I
will make no promises. Since I have some free time today and tomorrow I
will put it toward that goal (general readyness is a good thing :> )
What surprises me is why this is so late comming? The problems with dpkg
must have been known since day 1, why are we just now actively doing
something about it? I have some ideas after inspecting the dpkg code, but
they are just not nice to say :<
> > The way Debian's packaging system stores and maintains the package
> > information doesn't seem to involve all that much processing actually,
> > I've been laying out in my mind what it has to do and so far there hasn't
> > been terribly much, I will know for certain once I inspect the existing
> > code and comprare notes.
>
> The way Red Hat stores its information is a _lot_ faster (cf. the long
> startup time of dpkg when doing some operations).
It's written in perl! It's not terribly hard to optimize alot of the
operations that go on in dpkg, like the 'reading database' that can be
sped up 1000% using a binary cache file. The selecting dselected package
can be increased in speed by stripping out packages that are not selected
in any way from the status file (good idea?) or at least using a fast C
parser (easy to make, I have some simple ideas). The ftp method seems to
be the worst offender, it is just SLOW doing alot of things!
All of these problems seem to relate to the simple fact that dpkg/dselect
is written in Perl, C and C++ and only the perl bits share code -- and
then not completely. I looked at the ftp method and it didn't seem to use
the perl library the rest of dpkg does.. Weird.
Jason
Reply to: