Re: DEITY TEAM -- REQUEST FOR FUNCTIONALITY and COMMENTS
Here are my suggestions for the dselect replacement and comments on some
problems you need to think about:
1) Consider upgrading the package management tools in a first pass. This
would make sure that upgrades proceed with the latest dpkg features (and
may have prevented the need to manually install dpkg when going from
0.93 -> 1.1 This might also have enabled a way around the problems
installing the new TeTeX packages, and possibly have got round some of the
problems with epoch handling. I don't fully understand all the issues
here, and this approach might not have solved all these problems, but I can't
see any major issues with it.
2) Currently dselect uses dpkg -iGROEB which goes through all the packages
in a directory, checking if they should be installed, this has the
following probems:
a) It is slow (particularly a pain if only one package is to be
upgraded)
b) If the archive has problems, you may be stuck - the archives
should be fixed, but problems are inevitable.
i) If the archive contains two versions of the same
package, then dpkg can end up installing both, and the older version
remaining on the system (this can currently be fixed by upgrading manually
using dpkg -i, and dselect copes fine after this.
ii) If the archive contains a symlink to a package that
doesn't yet exist, then dselect/dpkg halts with an error, and may not
install/upgrade some packages. This problem occurs even if you don't want
the problem package.
c) There is no easy way of saying you want some unstable packages,
but don't want to upgrade the whole system to unstable (eg I'm prepared to
live with user level packages crashing, but not the basic system
packages). This was particularly a problem with non-free packages, though the
rearrangement of the archive should fix that.
3) Ideas for dependency/conflict resolution.
Currently whenever you select a package for installation that requires a
second package you don't have installed, dselect jumps to a conflict
resolution screen which can be disorientating. In yuor tool under X
(possibly elsewhere), you could have a second window popping up for
conflict resolution. This second window should have a "Solve my conflicts"
button, and list the package conflicts (with unrelated sets of conflict
split apart), but should still allow you to select packages from the
package selection window (perhaps they should be highlighted) and update
the conflicts window if necessary. This would mean you don't get shoved
straight into the conflict resolution screen when you are intending to
select the required packages anyway.
4) Xdselect (or whatever you call it) upgrading X
Currently, you need to use dselect from a console window to upgrade X
(X does now warn you it is about to stop X before it pull the rug
out from under you).
5) Xdselect running under non root user's X session.
By default, root does not have the necessary X cookies to write to the
display if another user "owns" the current X session. This is a problem in
my case for the following reason: Currently, I log into X using my normal
user account, and su to rool in an xterm if necessary. In order to run
"make xconfig" when building a kernel, I have symlinked root's .Xauthority
to my user level account, this works, but is not implemented by default,
and there is must be a better solution. Xdselect will have the same
problem.
6) Some means of telling me that a particular package really is obselete,
and what is the replacement that offers similar funtionality.
7) Floppy upgrade
The ability to transfer packages via floppy to upgrade an existing
system (more likely), or install a system from a stack of floppies
(probably not so common). This is already possible, but there are a
number of things that may be desirable (I anticipate I may have to do
this next year, but, so far I've only tried this once - installing
ghostscript one summer, so I may have misjudged some of the issues).
i) Packages that can fit on a 1.4M floppy - probably best to
implement by providing existing packages split to this size, possibly
on the fly.
ii) Dependency checking
It is a pain to download something, only to discover you need to
download other packages to make it work. There are various levels of
sophistication that could be used the two below possibly need
simplifying, but I like the idea of the first certainly.
a) A web site that listed the packages, and
essentially gave you the conflict resolution in dselect, and ended by
having a hotlist of all the packages you needed to download. A more
sophisticated version could perhaps store a version of your packages
file (though perhaps that has privacy concerns). A really
sophisticated version would suggest how to pack your floppies for
maximum efficiency.
b) Similar to (a) above, but the non networked machine
could generate a list of packages to be downloaded, and print it out,
or put it on floppy.
Hope these are considered useful suggestions.
Chris
Reply to: