Re: "dselect" replacement team
Jason Gunthorpe <email@example.com> writes:
> On Thu, 10 Apr 1997, Peter Iannarelli wrote:
> > Hi Guys:
> > If I understand correctly, one of the current problems
> > with the dselect/dpkg utilities is that there is a
> > potential that packages on a distribution could get out
> > of wack. By that I mean that dependancies are not
> > contained on a distribution, version problems may exist
> > and even binary files could be missing.
> Hm, It seems to me that many of those problems are caused by dpkg/dselect
> not ordering the packages for install right and/or the actual packages
> being incorrect. We can fix everything on the install side, but I don't
> think the projects scope should include manipulating the construction of
> packages till much later on (if at all). If there are specific problems
> with the packaging tools then something might be able to be done about it
> eventually by changing the exsting code or begining a new project to redo
> the packager.
> 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
> > If we minimize the amount of logistical processing during
> > install or upgrade a fairly lean, high performance install
> > facility should be no problem.
> 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).