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


"Christian Hudon" <chudon@ee.mcgill.ca> writes:

> On Apr 15, Dale Scheetz wrote
> > Isn't this already available with get_selections and set_selections?
> Yeah, but only 'oldtimers' know about that. I'd be nice if it could be
> integrated in a more user-friendly way into "dselect 2". Something like:
> Select Packages
>  - Full list (provides collapsible tree list of all the packages
>  - Package Groups (provides often-used configurations like 'C development
>      machine', web server, etc. to help newbies get a working system
>      quickly.)
>  - Read "Selection list" (for sysadmins doing installs of Debian on many 
>        machines)
> Of course, there should also be a way to save the "selection list" to a
> file somewhere.

In fact, I'd like this feature to work the following
way. --get-selection and --set-selection are useful, but are not
everything I want to have, mostly if a distribution (as often
happened to us in the last releases) is not completely consistent. The
control information doesn't always allow you to do what you want
therefore I'd like to have the following low-level change of how dpkg
keeps information about an installed package:

   an installed package should record whether non-standard
   force-options have been used at installation time
   (e.g. --force-depends).  

now for some dselect (or deity) changes:

 1) Both reading and writing of selection lists has to be possible
    directly from the gui interface using advanced selection lists as
    described below:
 2) A selection list has to include the neccessary force options for a
    clean install just using this selection file. If a fine-grained
    approach is not possible or wanted global force options should be
    included in the selection file. Using an unmodified selection list
    should result in a clean install without having to specify other
 3) Installing a read selection file should make use of a force option
    just for the package that needs it (if the fine-grained approach is
 4) There should be standard selection files available for several
    standard setups. Each selection files have to be authenticated (and
    maintained) just like a standard debian package.
    These maintained packages should be accessible directly from
    a dselect menu.
 5) It should be possible to include further global options (as
    e.g. network-aware installation using a nfs-mounted directory
    already containing the stuff to be installed there) in the
    selection file.
 6) Overriding stuff in a selection file should be warned against
    but it should nevertheless be possible to do so.
 7) there should be (maintained) partial selections (what above is
    called Package Groups) that include what's needed for a specific
    task. One should be able to merge several of them. These
    selections (or Groups) should work the same way as standard
    selections but more than one may be used at the same
    time. Relationships, i.e. compatibility, with other partial
    selections should be handled by dependencies and conflicts like
    those for packages. 

So far for the predefined selections. I have, however some more wishes
for the packaging system which are at least partly connected to the
main installation process:

Several further wishes I have (partly unrelated):

 - The GUI version must be aware that there are packages that can not
   be upgraded while it is running (e.g. xdm or the X
   server). Alternatively a safe upgrade procedure for those packages
   should be used when running the GUI. The latter is harder but may 
   be better in the long run as it's probably easier for people not
   intimate with the debian package manager. This needs, of course,
   cooperation with the concerned Maintainer(s).
   A way this could be done is as follows: those files that may not be
   touched when upgrading will be renamed and their new filename
   marked for deeltion by adding to a list for dpkg use.  Every now
   and then (but at least at boot time) the package manager (or a
   related script/program) should look at this list, determin whether
   a file is still in use and delete it if not.

Further global options I'd like to have for dpkg:

 - network-aware dpkg (parts of the file system from a non-local nfs
   server). This is really something that should be done. 
 - [*] excluding parts of a package from installation. This state of
   installation should be saved in the dpkg database.
 - [*] zlibc-aware dpkg
 - dpkg support for LANs using a database for packages that have to be
   installed on every machine in the LAN. If support for selections as
   mentioned above is realized, this is very easy. This would make
   maintainance of debian-LANs much easier.
 - multi-packages, i.e. a single (physical) package containing several
   different logical packages. An example where this could be useful
   is the X server. Having a single package (OK, it would be huge)
   using sophisticated setup scripts would make it much easier for a
   informationally challenged installer to pick the right package. The
   package could autodetect the right server to install.
   A second (perhaps easier) solution would be to have a new kind of
   package, one that can only be installed from within a
   "master-package". In the example above this would mean that there
   is a package xserver that contains just the setup scripts and the
   real X servers can only be installed from the setup scripts of this
   package. Currently such a thing is not possible as dpkg locks the
   database when installing which is of course a Good Thing. 
   Handling such a thing would require some special communication of
   the master-package's installation scripts and dpkg.

Options marked with [*] are options I'd deem to be of secondary
interest. It would be nice to have them but they usually would not be
needed for a more newbie-friendly environment, but for advanced
administrative use.

A further comment is that with using a GUI, I'd like to know how you
intend to bootstrap to a point where a GUI can be used. The X setup
stuff is much easier with XF86Setup, but there still are a lot of
cases where it doesn't work correctly. The current way does not use
any GUI while installing, using the two-stage installation approach. 
What I like to have as _optional_ bootstrap is a three-stage setup if
X is to be installed. Of course the standard way of using just the
console dselect should be supported in the future as well.

 1st stage: installation of base system including a basic question
            whether to install X. If X is to be installed goto stage
            2, otherwise use console dselect and stage 3.
 2nd stage: installation of the basic X Window system using the
            generic server to autodetect the optimal XFree86[TM]
            server to use. If this stage succeeds use GUI otherwise
            fall back to the console version for stage 3.
            The installer (i.e. the human being) should be able to
            force assumption of success of stage 2 using manual setup
            of the X server. This should be, however, warned against
            and both well documented in the installation notes and 
            to obscure for those who didn't read them to guess.
 3rd stage: select packages using our fine new dselect console or GUI
            version depending on stage 2.

All the selection stuff should happen in the 3rd stage.


Helmut Geyer                                Helmut.Geyer@iwr.uni-heidelberg.de
public PGP key available :           finger geyer@saturn.iwr.uni-heidelberg.de

Attachment: pgp2kS94jl8Js.pgp
Description: PGP signature

Reply to: