new Debian user's thoughts on Debian installation
I've been using Linux since 1992, RedHat since 3.0.3 (early 1996 when
I decided it was time to stop "rolling my own" releases), and UNIX in
general since 1987, so I hardly qualify as a newbie. However, I just
tried Debian for the first time this weekend. I decided to try Debian
this weekend because I'm philosophically much more inclined toward the
Debian model than something like RedHat and because I was appalled at
the instability of RedHat 7.0, especially the fact that it included a
developer snapshot of gcc....
I thought it would be useful to give some general observations as well
as one specific concern about the installation system. I installed
potato rather than woody because it was what I could get CDs for and
because I decided that I'd be better off evaluating a stable release
of Debian than an unstable one. :-)
I am a software developer by vocation and avocation. I build lots of
stuff from source (though there are Debian packages for almost
everything I build) and I sometimes run software directly from CVS
checkouts (zsh, sometimes sawfish, others when trying to report bugs,
etc.). The one really major annoyance with the Debian installation
system is that the -dev packages are always separate from the runtime
packages (a good thing) and there seems to be no way to automatically
get the -dev package corresponding to a runtime package (maybe a bad
thing?).
What would work for me would be to always get the packages required to
BUILD anything I choose to install, and to always get the -dev
packages corresponding a runtime package. I'll give some concrete
examples.
I use zsh and have been experimenting with the new completion system.
There are features that I'm using or testing that are not even in
-dev6, so I run zsh from the CVS repository. The zsh documentation is
in yodl. You don't need yodl installed to run zsh, but you do need it
installed to build zsh. Therefore, I'd like dselect to suggest
installing yodl when zsh is selected. (Maybe it already does -- I
didn't install the zsh package since it's too old for me.)
I use openssh which doesn't seem to exist even in the non-US area
(unless I just missed it). openssh links with libwrap. I got the
libwrap runtime libraries because of TCP wrappers, but I did not get
the development libraries. I had to go back and install the
development libraries. Additionally, openssh has a gnome askpass
program. I couldn't build it because gnome-config didn't get
installed.
I can think of a few solutions to this problem. One would be to have
some kind of "developer" option that would automatically select
developer modules that correspond to selected runtime modules and that
would automatically select packages required to build something and
not just to run it.
I haven't studied dpkg in depth yet, but I know rpm well, and, so far,
it seems that dpkg has a superset of rpm's functionality. If this is
the case, then it should be possible to specify build package
dependencies as well as runtime package dependencies in a control
file. It would obviously be up to the packager to get this right,
which they won't always do. In any case, control files can make
suggestions and can name requirements. At worst, all build
prerequisites should be suggestions, and at best, there should be a
separate category so that if you have the "developer" option enabled
at the time of running dselect, you'd get these. However, since this
is quite subject to the packager who could easily forget since he/she
probably already has all the development stuff installed, I've also
suggested that you should automatically get developer libraries for
runtime libraries if you are a developer. There.... that was not the
most clearly written paragraph I've ever produced, but I hope the
point is clear.
One could conceive of a similar type of flag for automatically getting
-doc packages that correspond to runtime packages. Likewise, server
packages that go with client packages.... With rpm, you can generate
multiple binary packages from one source package. I virtually always
install all binary rpms that go with a single source rpm which pretty
much gives me this functionality. I don't know whether Debian
packages work like this as well. One thing I notice is that there are
often mutually exclusive pairs of packages with Debian that probably
came from the same source such as sawfish and sawfish-gnome. This
kind of thing makes it kind of hard to select all packages from a
category and remove what you don't want rather than selecting just
what you want.
If any of what I've said above is wrong, represents a
misunderstanding, or is otherwise solvable under the current system,
I'd be grateful if someone could set me straight. :-)
Another thing is that it would be nice to control the order in which
the sections are presented. Using "o" from dselect and selecting Sort
by (avail., section) helps some, but I found that an alphabetical
presentation still wasn't what I wanted. I ended up generating a list
of all the sections from the directory structure on the CDs and then
just reordering them and going in that order. It's useful for example
to select from devel, libs, and doc near the end since a lot of
packages in those categories will get selected automatically as
requirements for other things. Basically, it's useful for the order
in which things are presented to be more based on dependencies than
alphabetical. I realize that this is easier said than done, and that
it is quite fuzzy since there isn't really a well-defined ordering
based on dependencies. Raw number of dependencies won't cut it. So
I'm not sure what the exact solution is. However, if the "task-*"
were presented before their components even in dselect, it would
probably be a good sign that things were working well. (While going
through devel, I started selecting autoconf, automake, etc. only to
finally get to the t's and see task-c++-dev and task-debian-devel
which required most of what I had already selected.)
Another thing that would be really nice to see in the installation
environment would be a running total of the amount of disk space
change that the selections will cause. You get this at the end after
you hit install, so the system obviously has enough information to
calculate it, but it sure would be nice to see it as you go. The
amount of free disk space I have strongly influences what I
select. :-) I'm more likely to optimize for time and select a bunch
of stuff I don't want if I know I've only used up 600 MB of my 2.5 GB
root. Likewise, I'm more likely to skimp on things like debugging or
profiling versions of libraries and documentation packages if I'm
running low on space. My casual reading of the packaging-manual
seemed to suggest that it is up to the packager to state how much
space their package takes installed. I hope I misunderstood this. It
seems like if dpkg just used the total size of the uncompressed files
that were being installed as a way to get the package size, the
results would be more accurate. If some package needs much more space
than the total size of the files because post installation scripts
generate stuff (like initex and all the format files) then there could
be some provision for the packager to indicate this, but even if not,
it shouldn't matter much because that kind of thing is ultimately
going to be in the noise in comparison to the overall installation
disk space requirements.
Some indicator during installation of percent complete would be
helpful too. RedHat has a slider with a percent complete and a time
remaining estimate. Obviously Debian can't do that because of the
fact that the installation is interactive where as the package
installation phase of RedHat's installation is completely hands-off.
On the other hand, it seems that Debian's package installation phase
is distinct from its setup phase. If a clearer line were drawn
between these phases and if all the configuration were done at the end
instead of once per CD, it might be a bit better. (This paragraph
should be taken with a grain of salt. I'm hurling around statements
without going through the required of making sure I'm right. Maybe it
isn't exactly the way I'm stating it with the various phases,
configuration steps, etc. but the basic point I'm making is that it
would be nice if there were some way to provide feedback at least at
certain points as to how close we are to being done, and I'm also
acknowledging that it's not necessarily straight forward. All in all,
I find Debian's method of forcing the user to configure at
installation preferable and safer than RedHat's method of installing
everything with defaults that you have to override. Forcing the user
to override defaults after the fact is asking for security holes
caused by default passwords, packages with dumb defaults (hard-coded
domains, IP addresses, etc.) and so on. It wouldn't be worth
sacrificing the per-package setup/configuration steps just so feedback
could be required. There. The parenthetical remark is longer than
the part of the paragraph that precedes it.)
These points were raised in what I consider decreasing importance.
Even if the only thing that were "fixed" were making the process of
getting a good development environment a little less painful, I'd be
much happier.
Another observation is that when I install a new version of RedHat,
I'm usually up and running with all my customizations (which I keep
documented) in an hour or two. I spent an entire day getting Debian
installed, and I started over several times to try different
approaches. Although this will undoubtedly improve as I get more used
to Debian, it still seems to be the case that the Debian installation
process is just going to take longer. This is probably because I'm
picky about what I have and want lots of control. To the Debian
installation system's credit, once the installation process was
finished, I had to do less customization and used up far less disk
space than a comparable RedHat installation (since I had a lot less
stuff I didn't use). These are all tricky issues -- an expert user
may find it easier to have a package installed with defaults and to go
edit configuration files once the system is up, a newbie would prefer
sensible defaults and not being asked a lot of questions, and a medium
user would probably prefer something in between.....
Well, if you've made it all the way to the end of this message,
thanks. I didn't think it was going to be so long when I started. I
hope these comments will be useful to the ongoing effort to improve
Debian in general and the installation system in particular.
--
E. Jay Berkenbilt (ejb@ql.org) | http://www.ql.org/q/
Reply to: