[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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: