Re: graphical apt, trials and tribulations
On Fri, 2002-05-24 at 11:11, Adam Heath wrote:
> On 23 May 2002, Seth Nickell wrote:
>
> > But right now I'm more interested in ideas people have about allowing
> > dpkg to be split into a libdpkg that gives feedback as it installs and a
> > dpkg command-line frontend (much as the split between libapt-pkg and
> > apt-get happens today). This is really critical to providing the user
> > with feedback during the install process. Right now we get nice feedback
> > as the packages are downloading and during setup to some extent, but
> > almost no feedback while the (potentially rather long) dpkg process
> > itself is occurring. I just say "Installing packages", but you really
> > should tell the user more for such a long operation.
>
> There will be no libdpkg. Use libapt-pkg.
I don't really care whether the functionality is a seperate library
called libdpkg or if its wrappered in libapt-pkg. Is the ability to get
status information during the setup and install phase already in
libapt-pkg and I've just missed it?
> I(a dpkg developer) have plans to make it possible to programatically drive
> dpkg. I've talked with Jason Gunthorpe(apt author) about what he wants. I
> may not have it implemented for dpkg 1.10(currently sitting in cvs HEAD), but
> will definately have it for 1.11.
Just my 2c (not that they really matter here but the thinking is
confusing me :-), what's the point in making this a STDIN/STDOUT
interface rather than a library? Libraries make it much easier to make
extra available to the client, they're a lot easier to deal with error
handling with (making them more robust), and they're easier to use for
clients. It looks like it would be rather easy to seperate dpkg into a
library (that libapt-pkg would use) and a commandline frontend. As long
as I don't end up using the STDIN/STDOUT interface directly and its
sufficiently reliable I don't really care, just wondering here...
> Additionally, there is already a dpkg --status-fd option(been there for quite
> a bit). However, the format of that output leaves much to be desired.
>
> The --command-fd listed in dpkg's help is currently disabled in the code.
>
> ps: I'm currently attempting to address several usability issues with dpkg for
> 1.10.
> * Fixing dpkg -S, so that it can handle symlinked top-level directories, and
> the like(this fixes hurd's dpkg-shlibdeps problems).
> * Fixing the speed of dpkg -S.
> * New features that would allow debconf to not call foo.config and
> foo.postinst directly.
>
> I may try to sneak in the above mentioned features needed by apt. Depends on
> time.
Sounds great.
thanks,
-Seth
--
To UNSUBSCRIBE, email to debian-gtk-gnome-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: