Re: dpkg upgrade/downgrade dependency problem
On Mon, Apr 13, 1998 at 02:38:16AM -0600, Jason Gunthorpe wrote:
> On Mon, 13 Apr 1998, Juan Cespedes wrote:
>
> > On Mon, Apr 13, 1998 at 10:13:09PM -0600, Jason Gunthorpe wrote:
> > >
> > > In my above pargraph consider 'dependencies' to be the general group of
> > > Depends:, Pre-Depends: and Conflicts:
>
> Yes, I know that in some cases Conflicts: is okay, but I never tested all
> the strange possibilities with Provides
>
> > > Juan, if you have some time I have a wonderfull idea for a much better
> > > interface to dpkg that would allow me to write some really nice error
> > > handling code.
> >
> > I'm afraid I won't have much time until July (exams :)), but
> > please tell us your idea.
>
> Ditto :>
>
> > BTW: I was also thinking in allowing something like this:
> >
> > # dpkg --install test-a_1.0.deb --remove test-b --unpack test-c_2.0.deb --configure test-d
>
> 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.
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.
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...
just my really 2 penny.
--
------------------------------------------------------------------------
Fabien Ninoles Running Debian/GNU Linux
E-mail: fab@tzone.org
WebPage: http://www.callisto.si.usherb.ca/~94246757
WorkStation [available when connected!]: http://nightbird.tzone.org/
RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
------------------------------------------------------------------------
--
To UNSUBSCRIBE, email to deity-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: