Re: X Configuration Interface for Debian
John Goerzen <jgoerzen@complete.org> writes:
> It doesn't quite seem to provide all the info, though. It appears to only
> list the installed packages, and doesn't put them into categories (mail, news,
> etc. and required, reccommended, extra, etc.)
-l is for list. You can use -s to find the status of a specific
packge. Just use 'dpkg --help'.
> It looks like a very good idea! I don't know why it isn't in use in Debian?
It's new; it will be integrated in 1.3.
Regarding your configuration tool, package installation and package
configuration are seperate problems. I think the easiest way to make
the former easier for novices is by doing two things:
1. Create meta-packages. Meta-packages are packages which don't
really contain anything in them but just have dependencies on several
different packages. For example, a meta-package called
"development-machine" might depend on gcc, binutils, *-dev, and any
other packages you would need installed to program.
2. Write a command ezpkg which can only do one thing - install
packages. The key is that when it installs a package it will first
read a Packages file and determine all packages which that package
depends on, and packages which those files depend on, etc. It will
then call dpkg to install all the packages. Its algorithm is trivial
- just some directed graph algorithms, namely reachable. (it's not a
dag, btw. cycles are allowed).
Now you're done. You can easily add some gratuitious graphical
interface to ezpkg so that a naive user can just click on
"development-machine", "Xserver", and "webserver" and all the
necessary packages get installed. The meta-packages should be
designed so that there are no conflicts (ie - any combination of them
is workable), but ezpkg would check this and present some nice error
message rather than let dpkg discover the error for you.
Regarding package configuration. The best way is really with Lars's
program. I think it needs one new feature, and there should be some
guidlines on variable naming and helpfile formatting.
1. The feature is variable types. These can be higher level than just
number and string. We could have username, filename, enums, etc. The
point is that the pretty frontend could be nicer if it could present
checkboxes, radioboxes. For username it could give you a picklist.
cfgtool itself doesn't need to check consistency (ie "cfgtool --set
happy.bool 3" doesn't have to return an error). It doesn't have to
understand the variables at all, besides storing them.
2. variable names should be of the format <package>_<variablename> and
no underscores in the package name. I chose underscore as the
seperator because we already don't allow them in packagenames. This
is needed so that the frontend
3. Help files should have a one line description as their first line.
Admittedely, with even more structure the variable type could be
stored here too. But this will entail xcfgtool having to read in all
the helpfiles for all the variables. We might want to add more
capabilities to variables later, so let's push this idea to cfgtool
and solve the more general problem...
4. cfgtool currently stores variables as 3-tuples (variablename,
value, helpfile). Let's make that of arbitrary length by allowing
variables to have attributes, and cfgtool stores the value for each
attribute. Value is just then another attribute, as are helpfile,
onelinedescription, type, etc. This can be done in 2 ways in cfgtool
itself - it has a preset list of attributes somewhere or they can be
made arbitrary. Both are pretty trivial to implement.
So perhaps the best thing is to junk the idea of helpfiles and
variable types and solve 4, the more general problem. Some new
variable attribute could then be added more easily.
Guy
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: