Debian Weekly News - email
To: Raphael Hertzog <rhertzog@hrnet.fr>
Cc: "Zephaniah E. Hull" <warp@whitestar.soark.net>,
debian-perl@lists.debian.org
Subject: Re: Release Plans (1999-05-10)
References: <19990510191255.A3990@whitestar.soark.net> <19990511075131.A824@k6.resI.insa-lyon.fr> <19990513091611.B21331@whitestar.soark.net> <19990513183200.A25881@p200.hrnet.fr> <19990513194357.A26441@p200.hrnet.fr> <19990513210946.A30591@whitestar.soark.net> <19990514084507.A1914@p200.hrnet.fr> <19990514032844.B30591@whitestar.soark.net> <19990514111249.A2979@p200.hrnet.fr> <19990514074520.C30591@whitestar.soark.net> <19990514150503.A16797@p200.hrnet.fr>
Reply-To: torin@daft.com
From: Darren Stalder <darren@u.washington.edu>
Date: 14 May 1999 15:44:54 -0700
-----BEGIN PGP SIGNED MESSAGE-----
Raphael Hertzog, in an immanent manifestation of deity, wrote:
>We should do the same for perl : all modules should use the latest perl but
>we may provide older perl for people needing it (but there's no point in
>providing modules for it exactly in the same way that we don't provide
>applications built with libc5).
>perl5.005 should be the official perl of Debian but perl5.004 would still
>be provided for convenience for perl developers.
>This is true if they do a partial upgrade. But can you explain me
>how you plan to solve this problem ? And not only for potato simply by
>telling that this won't be a problem as perl5.004 will be used ! How
>will you manage it the day we'll switch to perl5.005 ?
>The ONLY way to support completely partial upgrade and everything would be
>to :
>- rebuild all modules with the new perl5.004 (thus having a dependency to
> perl5.004)
>- wait that people use them and upgrade ALL of them (and you can't be
> certain of this because they may well do a partial upgrade !)
>- install perl5.005 and rebuild all modules for perl5.005 with the
> correct dependencies
There's a better plan than this. An empty perl package that depends on
the perl-5.004 package is uploaded. When someone upgrades Perl, it
automatically installs perl-5.004. The perl-5.004 package provides perl
and perl5. This means that the old perl package can be removed. So, we
have a variety of modules that depend on perl. We upload a perl-5.005
package. It provides perl5 but conflicts with perl. For someone to
install this package (without --force), they have to've upgraded all
their modules that depend on the old perl package. All new modules will
depend on perl5.
So, we have versioned Perls that can be partially upgraded without any
problems (that I perceive).
Packages can still depend on a particular version of perl-5.* if they
need to. The latest version of Perl will be the preferred version by
default with update-alternatives. It makes my base.{postinst,prerm}
script much easier. So, if both perl-5.004 and perl-5.005 are
installed, /usr/bin/perl will refer to 5.005 if the user doesn't change
things. When perl-5.006 is released, it will have precedence.
Raphael Hertzog, in an immanent manifestation of deity, wrote:
>So Darren what do you think about all this ? The final conclusion I've
>reached is that :
>- we should have a common directory for non-binary modules. I don't
> know if it should be /usr/lib/perl5 or a subdirectory of it.
It can be /usr/lib/perl5 for all non-binary Perl modules that don't come
with the Perl package. All modules that come with perl-5.\d+ will still
go into the versioned directories.
I don't see a reason for it to be other than /usr/lib/perl5.
>- we should always support the latest perl but leaving the old one
> available for developers. All the modules should be built with the
> latest perl. If for a reason or another a module for an older perl
> is needed, we should name it libmodule-perl-<oldversionofperl>. This
> situation may only arise for binary modules since non-binary modules
> share an unversionned directory common to all perls.
I agree with this...
>If the common directory talked about is not /usr/lib/perl5, then we'll
>still need /usr/lib/perl5 in @INC for perl5.005 in potato.
Actually, it would only need to be in perl-5.004 due to the method I
mentioned above.
Darren
- --
<torin@daft.com> <http://www.daft.com/~torin> <torin@debian.org> <torin@io.com>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI/Pilot programmer/tutor @
@ Make a little hot-tub in your soul. @
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBNzynVrQuaHP6LBjxAQH+qAP/WToQ3wl0gaX8Oq3RjMlgpMoCr8sv9brb
5FxTA1F6tpqzIAS969xDMQV7j80BiFHfehgaLnq633rJaCOIW+vTf9hIttu7LKwa
/I03rRAk3li7KHjC9+6j1P/pK4I+kFKnkiVBdJinV3iEQqmHYoKhgNh9uYxixpIL
7Tka1zE0SPM=
=StpG
-----END PGP SIGNATURE-----
Date: Mon, 17 May 1999 22:14:50 +0200
From: Stefan Gybas <cab@studbox.uni-stuttgart.de>
To: linuxconf@xc.org, debian-devel@lists.debian.org,
debian-admintool@lists.debian.org
Subject: FAQ and call for help: Linuxconf and Debian
Hi!
I'm getting a lot of mails full of questions about my Linuxconf Debian
package so I've put together a little FAQ (attached).
I also want to further intergate Linuxconf into Debian but this requires
a lot of work. If you want to help me with this please contact me.
If you want to reply to this mail please choose the right mailing list. For
general Linuxconf questions please use linuxconf@xc.org, for Debian specific
issues please use debian-admintool@lists.debian.org.
--
Stefan Gybas
1. What is Linuxconf?
Linuxconf is a program for Linux systems with three major functions:
(a) configuration utility
With Linuxconf you can do basic and advanced system administration
and configuration. Linuxconf has some core functionality (like
creating and managing users, groups and file systems) and several
modules for other system components, e.g. bind, apache, sendmail,
samba and squid. Currently there are over 20 modules available.
The configuration is done using a GUI with lot of help texts that can
either use a text, X11 or web interface.
Linuxconf does not use a database to store the configuration, instead
it just uses the normal system configuration files like /etc/fstab,
/etc/hosts - while trying very hard to preserve their structure (like
manually added comments). So you can always switch between a text
editor and Linuxconf.
(b) configuration activator and manager
Linuxconf can keep track of changes made to configuration files
(either using Linuxconf itself of some text editor) and then update
the system to reflect those changes. An example might be
vi /etc/inetd.conf
vi /etc/apache/httpd.conf
linuxconf --update # This will cause inetd and apache to
Another feature is the ability to archive and restore configuration
files (using RCS if available):
linuxconf --archive
linuxconf --diff
linuxconf --extract
(c) boot selector
The third main feature of Linuxconf is called askrunlevel and
this is exactly what it does. It shows a little menu during boot up
where you can select the system runlevel and the profile.
A profile is a name for an archived configuration (see section b)
like "office" or "home", so you can e.g. have different IP addresses
or XFree configurations with your laptop depending on your location.
Each of these features can be turned on or off independently, that means
you don't need to activate the boot selector if you just want to do some
Samba configuration. And you can always De-install the Linuxconf package
and everything is as it was before.
2. Where can I get the Linuxconf Debian package?
I've split up Linuxconf into four separate Debian packages:
linuxconf The main Linuxconf binary (text and web interface
only, with all modules)
linuxconf-x The X11 GUI for Linuxconf (this is in a sperate
package so the main package does not depend on
xlib6g, wxxt1 and xpm4g)
linuxconf-locale The foreign language files (all except English)
linuxconf-boot The boot selector (see 1c) - if you don't want to
enable this features, simply don't install this
package and Linuxconf will not make any grave
modifications to your system.
All packages are in the "experimental" distribution - available on
all Debian mirrors in project/experimental/. They can be installed
on a Debian 2.1 (slink) system but require a newer netbase package.
3. What is working on Debian GNU/Linux? And what is not?
All of the configuration stuff (see 1a) except network configuration is
working on Debian. The configuration activator (1b) and boot selector (1c)
are partly working (see question 4).
4. What needs to be done in order to make the other features work?
The problem with network configuration is that this is done differently
on each Linux distribution and thus Linuxconf does not know where to store
the host name, IP addresses and routing table. So distribution specific
modules were written to handle this part, but unfortunately there is none
available for Debian yet.
For the configuration activator, Linuxconf needs to know which config file
belongs to which service/daemon and how to make this daemon reload its
configuration. Again, this is distribution specific but Linuxconf has
a little bit basic knowledge here, e.g. it knows that inetd uses
/etc/inetd.conf and can be restarted using "kill -HUP".
But as you might probably know, Debian uses SysV init scripts in
/etc/init.d/ that can also make a daemon reload its configuration, like
in "/etc/init.d/proftpd reload". So it would be a good idea to tell
Linuxconf which init script starts which daemon(s) and which config file(s)
they are using. This is done using some special tags in those init scripts,
please read http://www.solucorp.qc.ca/linuxconf/tech/sysvenh/index.html
for details.
In recent versions of Linuxconf, those "init script tags" can also be
stored in different files, so they don't have to be in the init scripts
provided by the package maintainers, although the former would allow better
consistency (and this is the way it is done in Red Hat).
To summarize what needs to be done:
(a) Create the required tags for all possible init scripts, so Linuxconf
can use those init scripts to reload a configuration instead of using
its own built-in rules. Maybe at a later point these tags can even
be put inside the init scripts if this should become Policy.
(b) Write a Debian module to handle the network configuration. This
module would have to read in the current network configuration from
/etc/init.d/network and store the changes in this file. Unfortunately,
this file is currently very hard to parse (as it is a shell script that
can use variables and commands in any order) so this modules would
be very difficult if you want to preserve the structure of this file.
A proposal was made on Debian-devel to switch to a different network
configuration scheme using easy to parse files (see e.g.
https://lists.debian.org/debian-devel-9902/msg01420.html).
I think the only way for Linuxconf (and any other configuration tool)
to handle network configuration on Debian is to use this new scheme or
the Red Hat scheme so we could simply use parts of the Linuxconf Red Hat
module.
5. What are the future plans for the Linuxconf package?
I plan to upload one of my next releases to the unstable distribution
(potato) instead of experimental. I will not include the linuxconf-boot
package (which is providing the boot selector - see 1c) in this upload
as it might cause some trouble because of the not working network
configuration. It is also not very useful in Debian because the runlevels
2 to 5 are all equal and the network configuration in done in runlevel S
so Linuxconf has no way to disable network configuration if the user
selects this option in askrunlevel.
The Red Hat modules has PAM support, so you can e.g. change a user's
password using PAM. I will copy this part into a Debian module which
I hope to create soon.
But the first step should be to create files with the tags for the
SysV init scripts (see question 4) - this can be done step by step. Once
we have tags for most init scripts, we can tell Linuxconf to forget its
built-in rules and just use the information from the tags. I'm looking
for helping hands, so if you want to help, please read
http://www.solucorp.qc.ca/linuxconf/tech/index.html (especially
http://www.solucorp.qc.ca/linuxconf/tech/sysvenh/index.html) and then
mail me if you are still interested.
The next step could be to make network configuration work, but as
explained in question 4 above, Debian would have to adopt a new
/etc/init.d/network first.
To receive this newsletter weekly in your mailbox, subscribe to the debian-news mailing list.
Back issues of this newsletter are available.
This issue of Debian Weekly News was edited by Joey Hess.