dselect/dpkg daydreams
For what little a few suggestions which have probably already been
thought of are worth from someone with no time to implement them,
I thought I'd offer these thoughts on dselect and dpkg anyway:
1) Multiple access method params -- e.g. it would be nice not to have
to re-enter access method parameters just to update from non-us. Also,
for single packages that the authors only want distributed from
their site like kermit (used to?) it might be good to allow
additional access method entries to be present in the debian
package record so dselect could just go out and grab it.
2) Non .deb package items -- building on #1, if the optional
access method fields were present they could define components
that are not .deb files, like the netscape binary packages on
ftp.netscape.com.
3) Progress meters during package download would be a tasty bit
of icing to dselect. Also they would offer a clue on slower systems
as to whether you are in the download or "check for incomplete or
corrupt" stage. Speaking of which perhaps after a package has
been verified to be intact, just printing "... Good.\n" on the end of
the line would be nice.
4) Allowing installed packages to ride on hooks in dpkg so they
can respond when other packages are installed or removed. An
example of what I mean -- have a package "fvwm-debian-std-desktop" which
consists of a program that writes fvwmrc files based on a database
of package names/versions associated with menu items. Whenever a
package is installed or removed, dpkg would look for hook files and
find the fvwm menu writer program, which based on the name of the
package installed or removed would then add or remove a menu or perform
other desktop configuration changes. Package maintainers would also
have the option of invoking this program from the .deb scripts instead.
This divorces the various window managers and packages in such a way
that the obligation for adding the menu item can be shared between
the maintainer of the menu package for a given window manager and the
maintainer of each individual package. I'm sure there would be
other uses for this feature as well. Probably the hooks could just
be more script files in /var/lib/dpkg/info.
Finally, Debian could really benefit from a kind person riding up on
a big white 30G drive and giving them a enough space to store
a journal of older .deb files (maybe this already exists somewhere?),
and optimized binary distributions for different intel processors.
(Yes I know there isn't a huge performance difference in some cases
but it would definitely be a selling point to some.) Or heck,
even someone selling CDs with optimized binaries would be great.
--
Brian S. Julin
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: