Re: DEITY TEAM -- one comment
robert havoc pennington wrote:
> When I first installed debian I selected more packages than would fit on
> the disk, and so I ended up with tons of "broken packages" and had to
> install again. dselect recovered nicely (something other distributions
> don't do) but since each package has a predictable size it seems dselect
> could have predicted the problem, which would have been even nicer.
[...]
Unfortunately in some cases it is not so simple to check for space
availability as /var may be on one partition, /usr on another and /lib yet
somewhere else. Yet for most newbie installations it should be no problem (just
one partition anyway), those that made up many partitions probably already know
what the space requirements will be. Otherwise how did they decide on the
partition sizes !
Other suggestions:
*** 1
Yes for more size aware pakage management program
*** 2
Sorry, this one probably resemebles much other propositions. I will only give it
my own flavour.
Yes for a hierachical package display. You definitely need to be able to collapse
whole parts of them. The "grouping packages" would have 4 states:
- None of its packages are selected
- The default set of packages is selected. This is for newbies who want to do
C but who don't want to choose between the libc (with many different versions)
and the glibc, make and pmake... The "grouping package should contain *sensible*
defaults. This last point is probably the most difficult part particularly from a
diplomatic point of vue.
- Some packages selected but not the default set. Probably the user decided
that he wanted a slightly different set of packages.
- All packages selected. This would probably be very rare since some packages
are incompatible (e.g. emacs and xemacs)
The hierarchy need not be limited to two levels.
Of course the user *must* have the option to "open" the grouping package and
individually select the packages he wants.
In practice we could have something like:
D C <- Default package selection
. Objective C <- Not selected
X G++ <- Selected
X libg++
. Tex <- No tex package selected (and it is collapsed)
C Network <- Custom selection of network packages
D Emacs <- All the packages
X emacs
. xemacs
Open problem: how to affect the default package selection depending on the
packages that are available. I.e. probably all the Tex packages should be grouped
in the Tex grouping package. This may include X packages that you cannot install
if you did not install X. We would probably need inter-"grouping package"
"recommends" relations. Actual dependency problems are better left at the
individual package level. Then if the user installs X, the program should report
to the user (same way as for dependencies see below) that some packages that were
in the default state could now be installed (thus the four states listed above
would also apply to individual packages).
*** 3
The dependency conflicts also need to be enhanced. Perhaps instead of asking the
user each time the dependency conflicts should be logged and the user whould
choose when to handle them. Either at the end (seems necessary) or before via
some command. But the dependency mode should not jump on screen like a "jack in
the box".
*** 4
I do not like the "required", "optional"... organisation of the packages in
dselect. I find it confusing. This should be a package attribute (made clear) but
it should not influence the packages ordering on screen. Maybe it could be a
filter: show only required packages, optional packages.
*** 5
I would also like to be able to know which packages depend on the current
package. Because sometimes I would like to uninstall a package but do not like
the idea of going throught all the "dependency" recovery mechanism.
--
Francois Gouget
fgouget@club-internet.fr
--
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: