Re: config packages [Was: rm -r * and the default prompt]
=?iso-8859-1?Q?Nicol=E1s_Lichtmaier?= <firstname.lastname@example.org> writes:
> I see a `config package' as a package that includes/modifies other
> packages conffiles. Using packages for this is ignoring the concept of a
> package. What if you remove one of these packages? What if some programs
> whose files are modified are not installed? What if one of these programs
> is installed _after_ the config-package? Should the config-package depend
> on every progam it configures? config-packages will depend on changes in
> several packages...
I would not advocate implementing such a package this way. Most of
the config files that we would be interested in fixing for newbies can
include or source another file. Take sh-like shells for example. We
would have the /etc/profile file (that is the file provided by the
bash package) source another file (if it exists) that would be
provided by our hypothetical config-package. We can even use the
update-alternatives tool to sort out which config file will be soured
when multiple config-packages are present on a system. This is more
in line with what I was thinking.
Milan Zamazal <email@example.com> writes:
> 1. I don't know whether I like the idea of a single config package or not
> but I can see the following questions:
> - Is it easy/possible to maintain single config package for many
I don't think that it would be too difficult. Such a configuration
package would not include configuration data that are essential for
the operation of any part of a Debian system. This package would
contain only fluff -- that is, stuff to make the system look nicer.
Making such a package would involve collecting all of the preferences
that the developer feels would be useful or pretty and packaging them
together to share with others.
> - Isn't it better to let this work to each package maintainer because
> he does probably understand it very well? I don't think there
> are many (hundreds) packages which need some kind of newbie
> customization. If I understand it well it should be about ten to
> twenty files in `/etc/skel/'.
Adding preference changes to the files in /etc/skel has been discussed
before on this mailing list. If I recall correctly, it is generally
preferred that changes be made to the system-wide configuration files
rather than the /etc/skel files (for example, /etc/profile instead of
/etc/skel/.bash_profile). However, I think you are correct, there
shouldn't be a large number of packages that need a little boost to
> - On the other side wouldn't be better to let this configuration
> things to one package with one maintainer ("newbies manager"), who
> could watch newbies questions on debian.user etc. so he knows what
> the *real* problems are?
Thank you. You have just clearly stated my main argument for a
Finally, I feel that I should add a bit to the `rm -r *' discussion.
Wouldn't it be nice to provide newbies with the alias rm='rm -i'?
I've seen this done on the systems here at my school and on systems
where I have worked. This alias is usually defined in
/etc/skel/.profile (or some such file), so that it is present on all
new accounts. (Notice that I am talking about modifying the files in
the /etc/skel directory when I said above that this should not be
done.) This trick prevents a new user from inadvertently erasing
important files until which point he or she tires of confirming each
file deletion and learns how to edit his or her .profile to remove the
annoying alias. It's just a thought.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .