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 [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .