Re: [custom] Some issues for custom debian distributions
> "nvy" == Nikita V Youshchenko <[EMAIL PROTECTED]> writes: nvy> The thing I really don't like in debian-cd is the requirement nvy> to have a local mirror. I prefer to use apt-get (+apt-proxy) nvy> to fetch packages while building CD. I have a (currently nvy> ugly) script to do so; if anyone is interested I can (try to) nvy> clean it up and make it available. I'm quite interested in such a script. Is it available somewhere, so I (we) can test it and improve it (not that it needs improvements, of course! :) ). bye, andrea -- Andrea Glorioso [EMAIL PROTECTED] "There's no free expression without control on the tools you use"
Re: [custom] Some issues for custom debian distributions
Re: Re: [custom] Some issues for custom debian distributions [Bob Proulx <[EMAIL PROTECTED]>, Sun, Jul 27, 2003 at 11:10:40PM -0600, <[EMAIL PROTECTED]>] > > # check whether we run interactively > > [ "$PS1" ] || return > > > > (Something like that exists in Debian's /etc/skel/.bash_profile.) > > Uh, no. You are thinking of /etc/skel/.bashrc which does that. The > profile sources the bashrc unconditionally. Sorry - I screwed up the file names. FYI, the "source" is commented out in /etc/skel/.bash_profile: #if [ -f ~/.bashrc ]; then #source ~/.bashrc #fi (Maybe that should be changed - it would be a resonable default for users that don't want to edit/don't know how to edit .bash_profile.) > Bash already automatically loads up the bashrc file if it is not a > login shell. Loading bashrc is not the problem. It is loading up > functionality which traditionally exists in the profile which is the > problem. Only for interactive shells, quoting bash(1): When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists. This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of ~/.bashrc. Nevertheless, the above test for $PS1 is still useful if you source .bashrc in .xsession etc where you want variables, but no completion etc. Christoph -- Christoph Berg <[EMAIL PROTECTED]>, http://www.df7cb.de Wohnheim D, 2405, Universität des Saarlandes, 0681/9657944 pgpDanoNoJYAx.pgp Description: PGP signature
Re: [custom] Some issues for custom debian distributions
Christoph Berg wrote:
> The problem that one doesn't want things like .bash_completion read
> there is easily solved by
>
> # check whether we run interactively
> [ "$PS1" ] || return
>
> (Something like that exists in Debian's /etc/skel/.bash_profile.)
Uh, no. You are thinking of /etc/skel/.bashrc which does that. The
profile sources the bashrc unconditionally.
> So test for reading ~/.bashrc should be done first in X startup files,
> only reading ~/{.bash_,}profile if the former doesn't exist.
Bash already automatically loads up the bashrc file if it is not a
login shell. Loading bashrc is not the problem. It is loading up
functionality which traditionally exists in the profile which is the
problem.
BTW, I see a lot of people turn their terminals into login shells with
'xterm -ls' and the like in order to make every shell a login shell
and source their profiles. Which I think is a less than optimal
configuration and I avoid that myself.
Bob
pgpMenSL60IBd.pgp
Description: PGP signature
Re: [custom] Some issues for custom debian distributions
On Fri, Jul 25, 2003 at 05:58:31PM +0200, Petter Reinholdtsen wrote: > - Preconfigure the packages we install > > Using two different approaches: (1) Load answers into the debconf > database before the packages are installed using some home-make > scripts, and (2) rewrite/replace configuration files using > cfengine at the end of the installation if the package is unable > to configure what we want using debconf. I'm fairly satisfied > with this solution, but am not sure if the method used to feed > the debconf database is the best available. I believe the best > option would be to extend all the packages we use to make it > possible to configure everything we need using debconf answers. There is a package in Debian called dpsyco that is just for this kind of stuff. You create a package that you install and it sets things up for you. It has hooks for cfengine (I have never used them though so I do not know if they work properly. I use them to configure my servers. Regards, // Ola -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: [custom] Some issues for custom debian distributions
Re: Re: [custom] Some issues for custom debian distributions ["Nikita V.
Youshchenko" <[EMAIL PROTECTED]>, Sun, Jul 27, 2003 at 08:30:33AM +0400,
<[EMAIL PROTECTED]>]
> > if [ -r $HOME/.profile ] ; then
> > . $HOME/.profile
> > fi
>
> Sterictly saying, this is broken.
> /etc/profile, ~/.profile and other login shell rc files should be read by
> logic shells only, so if a user types "startx" on the console, they should
> not be read.
I've got stuff in my .bash_profile that I really only want on login
(finger, mailq on the mailserver etc.), and in fact I would be very
surprised if it were executed (in that case I could as well make a link
.xsession -> .bash_profile :-P). My .bashrc is much more suitable to be
included in .xsession, and in fact I do that.
The problem that one doesn't want things like .bash_completion read
there is easily solved by
# check whether we run interactively
[ "$PS1" ] || return
(Something like that exists in Debian's /etc/skel/.bash_profile.)
So test for reading ~/.bashrc should be done first in X startup files,
only reading ~/{.bash_,}profile if the former doesn't exist.
Christoph
--
Christoph Berg <[EMAIL PROTECTED]>, http://www.df7cb.de
Wohnheim D, 2405, Universität des Saarlandes, 0681/9657944
pgpwKZ4eT5Gsu.pgp
Description: PGP signature
Re: [custom] Some issues for custom debian distributions
> Nikita V. Youshchenko <[EMAIL PROTECTED]> wrote: > [...] >> Another thing is replacing "#!/bin/sh" by "#!/bin/bash --login" in >> /etc/kde3/kdm/Xsession (and other dm's Xsession files). This is the only >> way I know to make login shell startup files evaluated during X logins. >> This issue is known for ages, but it seems that people who make decisions >> don't thing it is necessary. So this isn't likely to be fixed with >> debconf questions. > [...] > > cat < /etc/X11/Xsession.d/60local_userenvironment > if [ -r /etc/profile ] ;then > . /etc/profile > fi > if [ -r $HOME/.profile ] ; then > . $HOME/.profile > fi > EOF > > This'll work for all display-managers that use the (Debian-)standard > /etc/X11/Xsession.d/. Sterictly saying, this is broken. /etc/profile, ~/.profile and other login shell rc files should be read by logic shells only, so if a user types "startx" on the console, they should not be read.
Re: [custom] Some issues for custom debian distributions
Andreas Metzler wrote: > Nikita V. Youshchenko <[EMAIL PROTECTED]> wrote: > [...] > > Another thing is replacing "#!/bin/sh" by "#!/bin/bash --login" in > > /etc/kde3/kdm/Xsession (and other dm's Xsession files). This is the only > > way I know to make login shell startup files evaluated during X logins. > > This issue is known for ages, but it seems that people who make decisions > > don't thing it is necessary. So this isn't likely to be fixed with debconf > > questions. That is one of the FAQs on the KDE site. http://www.kde.org/documentation/faq/configure.html#id2913380 9.7. KDE (kdm) does not read my .bash_profile!". The login managersxdm and kdm do not run a login shell, so .profile, .bash_profile, etc. are not sourced. When the user logs in, xdm runs Xstartup as root and then Xsession as user. So the normal practice is to add statements in Xsession to source the user profile. Please edit your Xsession and .xsession files This leads one to suggest what Andreas suggested: > cat < /etc/X11/Xsession.d/60local_userenvironment > if [ -r /etc/profile ] ;then > . /etc/profile > fi > if [ -r $HOME/.profile ] ; then > . $HOME/.profile > fi > EOF > > This'll work for all display-managers that use the (Debian-)standard > /etc/X11/Xsession.d/. I originally went down this path as well. I thought the same thing and implemented the same solution. (I put it in 95user_env so that it was very late in the process.) But there are some problems with doing this. 1. The Xsession is currently run in 'set -e' mode and any non-zero return value from a command will stop the shell process. Running in 'set -e' mode is not a normal mode for running a .profile. Many users will execute commands which will have a non-zero return code. This is not an error. This is just by normal script operation. The effect is that the user cannot log in. 2. Many users will source /etc/bash_completion in their startup file. That should be fine if they are running bash. But the Xsession scripts are running as /bin/sh and it will not be happy parsing bash_completion. The effect is that the user cannot log in. 3. Many users do not use .profile but instead use .bash_profile, .zprofile, .login, etc. Which means that suddenly Xsession needs to know about not only the filename of every viable shell but also the syntax of every viable shell. The effect is that some users do not get their startup environment set up while others do. After having gone through the experience of implementing this and having many users suddenly unable to log in I have new appreciation for the problems the KDE developers face. If they pull in the user's environment then problems there will prevent users from being able to log in. The user won't be happy, even if it is their fault, and the KDE developers will get a bug report even though it is not their problem. (Yes I know the user can either console login or failsafe login and fix their problem. But assumes the user knows it is their problem. It also assumes that the user wants to add workarounds to their startup files to control functionality between KDE login and other logins. I know I don't want to do that myself.) I did not originally agree with the KDE decision not to source the user environment. I was dismayed to see that I was not getting my environment. But I now agree with their choice not to load the user files by default. Because without loading other files then a user can select KDE from the login manager and log in and any problems in that path are solely a KDE problem. If KDE works then they are in. But as soon as you open it up to loading user files you are opening yourself up to an unbounded list of perfectly valid user configurations which cause problems, such as sourcing bash_completion, which will prevent the user from logging in. Is there no hope? Yes there is hope. I think there is a middle ground. The answer I am happy with and have implemented is providing a user $HOME/.xsession. Here is what I use. #!/bin/sh PATH=$HOME/bin:$PATH:. exec x-session-manager That is all of the fixup I need but it does provide the hook to do any customization that is desired. Actually, I personally put /usr/sbin and /sbin in the PATH too. But I don't default users to that. If someone knows they can do it easily enough. Additionally since I use fvwm I start it instead of kde. #!/bin/sh PATH=$PATH:/usr/sbin:/sbin PATH=$HOME/bin:$PATH:. exec fvwm With this in place I should give a clarification of the login manager process. Let me give a typical example. The menu selection will allow the user to choose default, failsafe, kde. Picking default gets you the $HOME/.xsession file if one exists. In the example above I get my selection fvwm. If a user picks kde then the login manager does NOT run the users's $HOME/.xsession file and instead just starts up KDE in the way that it does now withou
Re: [custom] Some issues for custom debian distributions
On Sat, Jul 26, 2003 at 09:24:55PM +0200, Andreas Metzler wrote: > Javier Fern?ndez-Sanguino Pe?a <[EMAIL PROTECTED]> wrote: [somebody broke attributions here] > >> Introducing an ~/.environment which would be evaluated by pam_env would > >> really be nice. > > > Isn't /etc/environment read too? Because that is what base-config modifies > > IIRC. > > Yes or no ;-) Currently pam_env does read /etc/environment but it does > not read ~/.environment. Yow. Guess I'd better get round to renaming my ~/.environment (which is a shell script, definitely not something suitable for reading by pam_env) sometime soon then ... -- Colin Watson [EMAIL PROTECTED]
Re: [custom] Some issues for custom debian distributions
Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> wrote: [...] >> Introducing an ~/.environment which would be evaluated by pam_env would >> really be nice. > Isn't /etc/environment read too? Because that is what base-config modifies > IIRC. Yes or no ;-) Currently pam_env does read /etc/environment but it does not read ~/.environment. cu andreas
Re: [custom] Some issues for custom debian distributions
On Sat, Jul 26, 2003 at 05:51:35PM +0200, Andreas Metzler wrote: > cat < /etc/X11/Xsession.d/60local_userenvironment > if [ -r /etc/profile ] ;then > . /etc/profile > fi > if [ -r $HOME/.profile ] ; then > . $HOME/.profile > fi > EOF > > This'll work for all display-managers that use the (Debian-)standard > /etc/X11/Xsession.d/. That's a very interesting approach! I did not know this was possible when I sent additional information to #147091. Maybe that's something that language-env (or user-XX) should do upon installation to set the proper locale for X environments also. > > Introducing an ~/.environment which would be evaluated by pam_env would > really be nice. Isn't /etc/environment read too? Because that is what base-config modifies IIRC. Regards Javi pgpq6IktvNwKh.pgp Description: PGP signature
Re: [custom] Some issues for custom debian distributions
Nikita V. Youshchenko <[EMAIL PROTECTED]> wrote: [...] > Another thing is replacing "#!/bin/sh" by "#!/bin/bash --login" in > /etc/kde3/kdm/Xsession (and other dm's Xsession files). This is the only > way I know to make login shell startup files evaluated during X logins. > This issue is known for ages, but it seems that people who make decisions > don't thing it is necessary. So this isn't likely to be fixed with debconf > questions. [...] cat < /etc/X11/Xsession.d/60local_userenvironment if [ -r /etc/profile ] ;then . /etc/profile fi if [ -r $HOME/.profile ] ; then . $HOME/.profile fi EOF This'll work for all display-managers that use the (Debian-)standard /etc/X11/Xsession.d/. Introducing an ~/.environment which would be evaluated by pam_env would really be nice. cu andreas
Re: [custom] Some issues for custom debian distributions
Nikita V. Youshchenko wrote: > E.g. in a "distribution" (better to say - custom installation CD) I maintain > here I expect users to use kppp to connect to their ISPs. To make this work > by default, I have to comment out whole contents of /etc/ppp/options during > the last stage of the installation. I don't think that pppd maintainer will > agree that such thing should be provided by debconf. > > Another thing is replacing "#!/bin/sh" by "#!/bin/bash --login" in > /etc/kde3/kdm/Xsession (and other dm's Xsession files). This is the only > way I know to make login shell startup files evaluated during X logins. > This issue is known for ages, but it seems that people who make decisions > don't thing it is necessary. So this isn't likely to be fixed with debconf > questions. This is the kind of thing that dropping a script in /usr/lib/base-config can help you with. > The thing I really don't like in debian-cd is the requirement to have a > local mirror. I prefer to use apt-get (+apt-proxy) to fetch packages while > building CD. I have a (currently ugly) script to do so; if anyone is > interested I can (try to) clean it up and make it available. I would much rather see debian-cd work that way. > Seems that feeding correct value to debconf for "locales" package fixes > this. At least for me. > > Currently I install "locales" and "console-cyrrillic" (with all > dependencies) very early - I modified debootstrap to do so. Default values > to debconf database also are written by modified debootstrap. So I have > russian properly set up already when base-config runs. base-config 1.41 and above modify /etc/locale.gen and run locale-gen to set up the installation locale before it goes interactive. If this doesn't work I would appreciate bug reports and patches in this area. -- see shy jo pgpU6Z4s3VoEd.pgp Description: PGP signature
Re: [custom] Some issues for custom debian distributions
Quoting Tore Anderson ([EMAIL PROTECTED]): > well), as I've seen far too many packages which ask Debconf questions > way out of proportion, carelessly ignore policy 11.7.3 (cf. the "manage > with Debconf madness" thread), etc. So even though it is possible to I hope you didn't forgot to file bugs for this For sure, there *is* a real debconf madness. During the debconf translation work we often find packages which make a huge abuse of debconf questions, asking for everything to be configured, or showing useless silly notes. Maintainers also often misuse priorities. You will event find packages which have only "high" priority questions. These deserve bug reports. The "switch to po-debconf" current work offers us a good opportunity for reviewing the use of debconf questions. When I submit a patch for po-debconf switch, I sometimes have to suggest removing some templates...or lower thepriority of others. Having a lot of debconf questions is not bad by itself. However, the majority should then be marked of "low" priority as long as they are notes to users and/or Choices with reasonable defaults.
Re: [custom] Some issues for custom debian distributions
It's really good news that someone is writing on this. Since Debian is somewhat hard to install and configure for unexperienced user, but otherwise Debian is The Best :), I guess many people are doing custom Debain installation tools. > - Preconfigure the packages we install > > Using two different approaches: (1) Load answers into the debconf > database before the packages are installed using some home-make > scripts, and (2) rewrite/replace configuration files using > cfengine at the end of the installation if the package is unable > to configure what we want using debconf. I'm fairly satisfied > with this solution, but am not sure if the method used to feed > the debconf database is the best available. I believe the best > option would be to extend all the packages we use to make it > possible to configure everything we need using debconf answers. I'm not sure that everything can be done this way. E.g. in a "distribution" (better to say - custom installation CD) I maintain here I expect users to use kppp to connect to their ISPs. To make this work by default, I have to comment out whole contents of /etc/ppp/options during the last stage of the installation. I don't think that pppd maintainer will agree that such thing should be provided by debconf. Another thing is replacing "#!/bin/sh" by "#!/bin/bash --login" in /etc/kde3/kdm/Xsession (and other dm's Xsession files). This is the only way I know to make login shell startup files evaluated during X logins. This issue is known for ages, but it seems that people who make decisions don't thing it is necessary. So this isn't likely to be fixed with debconf questions. > - Automatic X configuration > > Using home-brewed script filling the debconf database, and then > call dexconf from the xfree86 package to generate the > configuration file. The HW detection info is fetched from > various packages (discover, kudzu, detect, etc). Could you give an URL to such script? I need one badly. Unfortunatly, discover/mdetect/read-edid based dexconf is far from perfect, especcialy in detecting capabilities of the monitor. And hadrware detection is not what I am an expert in :(. > - CD building > > Using a heavily patched version of debian-cd to create the CDs. > Most of the patches is to include the d-i boot floppies. This > should now be possible with the standard version of debian-cd, > but no one in Skolelinux have taken the time to update our copy > of the scripts. The thing I really don't like in debian-cd is the requirement to have a local mirror. I prefer to use apt-get (+apt-proxy) to fetch packages while building CD. I have a (currently ugly) script to do so; if anyone is interested I can (try to) clean it up and make it available. > - Configure default language for all users > > Using a custom script to rewrite config files to modify the > default language/locale. Seems that feeding correct value to debconf for "locales" package fixes this. At least for me. Currently I install "locales" and "console-cyrrillic" (with all dependencies) very early - I modified debootstrap to do so. Default values to debconf database also are written by modified debootstrap. So I have russian properly set up already when base-config runs. > There are probably others, but this should be a good starting point. > Are these issues common to other custom distros? Main problems I current have are related to hardware detection and configuration. Users want to configure their X display easily (resolution, frequency, etc). E.g. from KDE control center. They complain that other distros let them to do so. I am not familar with distros other than Debian so I don't know what to do. Also users want all their hardware to be detected and configured automatically. Well, discover does something, but again, users complain that XXX is not detected/configured/working properly, while everything is ok with other distros. Maybe there are better tools? Please share your experiense.
Re: [custom] Some issues for custom debian distributions
Petter Reinholdtsen wrote: > - Installing the list of package we want > > Using meta-packages (ie packages consisting only of dependencies) > to install the packages we want. Used hooks in base-config to > get them installed during first time installation. Not too happy > about the meta-package approach, as it is fragile and break > easily if some dependency is unavailable. If you need to generate your own Packages files, which you might want to do for various reasons, you could instead add Task: overrides to the Packages files. Then use 'tasksel install' (that command may need to be fixed first) to install the task. This would sidestep the dependency problem. Alternatively, you could get a similar effect by making the task package only recommend most of the stuff in the task (except perhaps a few key packages), and installing it with aptitude, which can pull in recommends. I am actually thinking about switching tasks back over to real packages using recommends like this, a few years down the road. I would be interested in the results of a test case. > - Preconfigure the packages we install > > Using two different approaches: (1) Load answers into the debconf > database before the packages are installed using some home-make > scripts, and (2) rewrite/replace configuration files using > cfengine at the end of the installation if the package is unable > to configure what we want using debconf. I'm fairly satisfied > with this solution, but am not sure if the method used to feed > the debconf database is the best available. I believe the best > option would be to extend all the packages we use to make it > possible to configure everything we need using debconf answers. As discussed at DebConf, I would like to make debconf have better support for pre-populating a database, when I find some time to work on it. > - Configure default language for all users > > Using a custom script to rewrite config files to modify the > default language/locale. Could this fit into the language-env package somehow? Debian needs to go a few steps further in providing a localised system after install, with language and locale set to the install langage. At the moment language-env only displays a stupid debconf message when installed, and allows per-user configuration, but it seems the place to put a global config too. -- see shy jo pgp8otr5dUntU.pgp Description: PGP signature
Re: [custom] Some issues for custom debian distributions
* Tore Anderson >> God, No! There's far too many Debconf questions being asked by >> various Debian packages already, IMNSHO. * Petter Reinholdtsen > There is no reason for you to get religious over this question. > > The nice thing about debconf is that there is no _need_ to present all > options as questions. One can like ntp fetch the value from debconf > without asking the question first. This will make it possible to > control the details of the package configuration without needing to > ask a lot of questions to the user while installing it. Which is why I suggested these "questions" should not be shown to the user at all, but merely exist as default values that could be over-ridden by custom distributions such as Skulelinux. However, doing so would remove the conffile status of many configuration files, which I firmly (perhaps not religious, though) believe is a bad thing. If a configuration file *can* be a conffile, it should. I am sceptical to endorsing use of Debconf for packages that can be shipped with sane defaults (even though these might not suit Skulelinux well), as I've seen far too many packages which ask Debconf questions way out of proportion, carelessly ignore policy 11.7.3 (cf. the "manage with Debconf madness" thread), etc. So even though it is possible to configure as much as possible through Debconf without actually asking too many questions and still caring for user modifications, I seriously this is the way it actually will be done. Thus I would rather see Skulelinux divert away unfitting conffiles. -- Tore Anderson
Re: [custom] Some issues for custom debian distributions
Hi On Fri, Jul 25, 2003 at 05:58:31PM +0200, Petter Reinholdtsen wrote: [...] > - Configure default language for all users > > Using a custom script to rewrite config files to modify the > default language/locale. Why not having multiple languages per user? I mean for example: 1) French 2) German 3) English That means first displays me info in French, if the translation is missing, then use German, finaly if neither French and German are available displays English I am very enthusiast about the items you exposed. Cheers, -- Pierre Machard <[EMAIL PROTECTED]> TuxFamily.org <[EMAIL PROTECTED]> techmag.info +33(0)668 178 365http://migus.tuxfamily.org/gpg.txt GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87 pgp3HBxMQnZnu.pgp Description: PGP signature
Re: [custom] Some issues for custom debian distributions
[Tore Anderson] > God, No! There's far too many Debconf questions being asked by > various Debian packages already, IMNSHO. There is no reason for you to get religious over this question. The nice thing about debconf is that there is no _need_ to present all options as questions. One can like ntp fetch the value from debconf without asking the question first. This will make it possible to control the details of the package configuration without needing to ask a lot of questions to the user while installing it.
Re: [custom] Some issues for custom debian distributions
On Fri, 25 Jul 2003 18:28:27 +0200 Tore Anderson <[EMAIL PROTECTED]> wrote: > * Petter Reinholdtsen > > > - Preconfigure the packages we install > > > > I believe the best option would be to extend all the packages > > we use to make it possible to configure everything we need > > using debconf answers. > > God, No! There's far too many Debconf questions being asked by > various Debian packages already, IMNSHO. > > If something like this should be implemented, I'd like to see these > questions only be asked at reconfigure time, or not asked at all. > That way Skulelinux could preseed the Debconf database and get the > package working the way you want, while I can install Debian without > going nuts about all the questions I'm asked. > If is debconf used 'the right way' (tm) it is only a blessing. The only thing maintainers should do is assign the right priority to a question (Well and of course take care that all changes to configuration files are preserved). That way people that want automation or just like questions get what they want and people that want to rewrite configuration files just set a high priority and get a nice and quite apt-get update/install. grts Tim
Re: [custom] Some issues for custom debian distributions
* Petter Reinholdtsen > - Preconfigure the packages we install > > Using two different approaches: (1) Load answers into the debconf > database before the packages are installed using some home-make > scripts, and (2) rewrite/replace configuration files using > cfengine at the end of the installation if the package is unable > to configure what we want using debconf. I'm fairly satisfied > with this solution, but am not sure if the method used to feed > the debconf database is the best available. I believe the best > option would be to extend all the packages we use to make it > possible to configure everything we need using debconf answers. God, No! There's far too many Debconf questions being asked by various Debian packages already, IMNSHO. If something like this should be implemented, I'd like to see these questions only be asked at reconfigure time, or not asked at all. That way Skulelinux could preseed the Debconf database and get the package working the way you want, while I can install Debian without going nuts about all the questions I'm asked. However, the best solution I can think of right now would be to implement diversion support for conffiles in dpkg, so you could create a 'skolelinux-config' package which contained (or generated) configuration files attuned to Skulelinux, where necessary. -- Tore Anderson
[custom] Some issues for custom debian distributions
As discussed during debcamp in Oslo, all the groups/projects making debian based custom distributions should join together to find common solutions to the common problems. This is a start, with a few of the issues that Skolelinux had and solved. - Automatic installation Using the new debian-installer and a few hooks to get the partitioning we want and the packages we want installed into the hard drive. I'm fairly satisfied with this solution. - Installing the list of package we want Using meta-packages (ie packages consisting only of dependencies) to install the packages we want. Used hooks in base-config to get them installed during first time installation. Not too happy about the meta-package approach, as it is fragile and break easily if some dependency is unavailable. - Preconfigure the packages we install Using two different approaches: (1) Load answers into the debconf database before the packages are installed using some home-make scripts, and (2) rewrite/replace configuration files using cfengine at the end of the installation if the package is unable to configure what we want using debconf. I'm fairly satisfied with this solution, but am not sure if the method used to feed the debconf database is the best available. I believe the best option would be to extend all the packages we use to make it possible to configure everything we need using debconf answers. - Automatic X configuration Using home-brewed script filling the debconf database, and then call dexconf from the xfree86 package to generate the configuration file. The HW detection info is fetched from various packages (discover, kudzu, detect, etc). - CD building Using a heavily patched version of debian-cd to create the CDs. Most of the patches is to include the d-i boot floppies. This should now be possible with the standard version of debian-cd, but no one in Skolelinux have taken the time to update our copy of the scripts. - Configure default language for all users Using a custom script to rewrite config files to modify the default language/locale. - Making simpler KDE menus Working on a system to make simple menus and change the menu depending on the users group membership. There are probably others, but this should be a good starting point. Are these issues common to other custom distros? How did you solve the problem?
