"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
options.
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
available).
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.
Greetings,
Helmut
--
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