Re: dpkg upgrade/downgrade dependency problem
On Wed, Apr 22, 1998 at 08:53:48AM -0400, Fabien Ninoles wrote:
> >
> > This is useful [well there is the command line length limit, 200 packages
> > would yeild ~800 options..], but not nearly as good as my latest great
> > idea.
> >
> > My current scheme would be to have APT open a bi-directional control pipe
> > to dpkg. It would issue a command (remove, unpack, configure) and dpkg
> > would do it and then report it's result - the two would run in lockstep.
> > (this also allows for some very interesting GUI's)
> >
> > This way I can deal extremely effectively with errors that happen,
> > transparently holding back packages that depend on the failed package,
> > giving an error summary at the end of the whole operation (like dpkg does
> > - but when apt exits) making sure the proper packages get configured and
> > so on.
> >
> > As it is, APT gives up the instant dpkg gives an error, it has no real way
> > of knowing exactly which package failed and why. Furthermore because dpkg
> > continues on after an error the result is typically a confusing set of
> > error messages. (Ie, kbd fails, then sysvinit fails because kbd failed,
> > and so on) and even worse, in long strings the error message and summary
> > tends to scroll past the user.
> >
> > This also fixes the problem with dpkg loading it's status database again
> > and again, but that is minor in comparision to decent error handling.
> >
> > Jason
> >
>
> Sorry of being late to reply to this one... I think about this idea a lot
> and I think it should be fine to have it done through RPC or through out
> some sockets. This will allow any debian workstation to be administrated
> remotely easily. Moreover, this will allow to separate more of the code
> for package management out of dpkg, making it a low level client.
Better, we should recode the dpkg "backend" to REALLY not care about dependencies
or anything of the like. Make JUST a program which will unpack, configure, remove,
etc. This can supply RPC, etc.
Then, make the dpkg command-line "frontend" use this backend. To some extent this
is already the case, with dpkg-deb, BUT dpkg-deb does not update the status files,
etc.
> May be this will allow also to keep a cache of the files and the packages
> more uptodate, letting dpkg load it instead of reparsing all the .list
> files.
The .list files should be in a true DB because:-
1. Any more packages, and dpkg will start to REALLY strain 4MB systems. As it is,
it is slow. Not loading every one of these files into RAM means saving a lot
of RAM - not all of them are needed.
2. The speed is atrocious at reading them. It feels like running on a 386 because
this bit takes SO long.
Updating the cache from the files would be simple. As would updating the files as
the cache is updated. In fact, I'll start on some code to cache the .list and
.conffiles. I can do this relatively quickly, now that I have a much clearer
timetable (I have finished all the major projects for this year's round of exams).
> OTH, I don't know that much about sockets and the like. May be a standalone
> tool will be necessary to allow reparation of the db...
Yes - but it can be the same program (although this is a waste of memory)...
I'll code using Berkeley libdb - SQL is too big, dbm is too old and bad.
--
Tom Lees <tom@lpsg.demon.co.uk> <tom@debian.org> http://www.lpsg.demon.co.uk/
PGP Key: finger tom@master.debian.org, http://www.lpsg.demon.co.uk/pgpkey.txt.
New, PGP 5.0 key at http://www.lpsg.demon.co.uk/pgpkeys.asc.
--
To UNSUBSCRIBE, email to deity-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: