Re: graphical apt, trials and tribulations
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(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.
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.
--
To UNSUBSCRIBE, email to debian-gtk-gnome-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: