Bug#40766: Rewrite of configuration files section
On Sat, Jul 17, 1999 at 08:08:36PM +0200, Stefan Gybas wrote: Why is a program in the package allowed to change a conffile but not the postinst? The final result is the same: dpkg might ask if I want to replace the configuration file when I upgrade the package. I, for example, maintain gnujsp (a Java servlet) which depends on libapache-mod-jserv (a Servlet engine for Apache, also maintained by me). gnujsp's postinst modifies some conffiles of JServ so can be used right after it is installed (all changes are reverted when gnujsp is purged). With your suggestion, I would have to move some parts of gnujsp's postinst to a script into the JServ package and call that script from the postinst instead. Whenever I need to make a change to this script, I have to upload a new JServ package (or even worse ask another maintainer to update the script if I was not the JServ maintainer). In short, you may not automatically modify the conffile of another package, either from your postinst or from a program called from your postinst. Programs in the package are allowed to modify conffiles. For example, packages like fvwmconf and dotfiles are intended to modify the configuration files of particular programs, which mean they will modify conffiles of other packages. That's perfectly fine -- it's no different to editing them with vi. As stated above, the result is the same: We have a modified configuration file in both cases. So what should I do? Let the user do the changes to the configuration files? Ask a lot of questions in the postinst? IMHO the automatic setup in the postinst is a very user friendly solution. It's a very friendly solution, but later dpkg will ask them about upgrading configuration files they've never heard of. You should lobby the maintainer of the package's conffile you want to modify to give you a mechanism (like updated-inetd etc) to do so. Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Re: Data section (#38902)
-BEGIN PGP SIGNED MESSAGE- One comment from the ferret: Would it make any sense to divide the 'data' section into main/contrib/non-free, instead of becoming a fourth section alongside them? I can't think of any examples offhand, but I could see where some datasets might have restricted redistribution. On Fri, 16 Jul 1999, Darren O. Benham wrote: On Fri, Jul 16, 1999 at 02:35:04PM -0700, Joey Hess wrote: Data section (#38902) * Stalled for 1 week. * Proposed on 3 Jun 1999 by Darren O. Benham; seconded by Peter S Galbraith, Peter Makholm and Peter Makholm. * Since there is interest in packaging census data, maps, genome data and other huge datasets I and since most people agreed that dropping them in main or contrib is not a great idea, I propose the creation of a data section to reside along side of main, contrib and non-free. Includes rules about what goes in this section. So what's the next step? Nobody appears to be objecting to this idea... All comments have been favorable... -- Please cc all mailing list replies to me, also. = * http://benham.net/index.html[EMAIL PROTECTED] * * * ---* * Debian Developer, Debian Project Secretary, Debian Webmaster * * [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] * * [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] * = -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQEVAwUBN5EsStZwc6w4vgodAQEGGAgAqrMmX9UwL+rexnot0O/8txADVeI0eXNJ Kqwf62iBJ3hVSKRVkAlcspCfYz6bTbpB0dTSg3aXhCO2/8Cyl5xs42RJc+6XoqgF k/VGzDiXytaObzk2KfebIdfGvp/aSSvCBzOWLi/+ypU/JP6EcGdugp20gC56KYiE ufvzFYUAwLsBy7kAz5BSqdux8yIWTKJnogOqDluBDWiNmchCGKYLyyexHWQcDVL4 U3U4BDxxAOyvlNXmPIEjM58yfsUx8cgA1RL2nSEhzu0ZuaDLL84Y1Z+NiU0/iqV/ FDS5FwDenV+GfE6hxXzNL8GsqCL+pdM1MDGvGH20JJP6FhkKtbbXLQ== =Cegk -END PGP SIGNATURE-
Bug#40706: AMENDMENT 17/7/99] /usr/share/doc vs. /usr/doc transition
-BEGIN PGP SIGNED MESSAGE- On 17 Jul 1999, Manoj Srivastava wrote: PROPOSAL: Easing the transition from `/usr/doc' to `/usr/share/doc' --- Manoj Srivastava [EMAIL PROTECTED] $Revision: 1.3 $ I second this proposal. - -- William Ono [EMAIL PROTECTED] PGP key: 0x93BA6AFD fingerprint = E3 64 C5 43 3E B3 2D A6 C6 D7 E3 45 90 24 78 DE = fingerprint PGP-encrypted mail welcome! 640k ought to be enough for everybody. -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv iQEVAwUBN5E04jZejXGTumr9AQHTNwgAmaj6ELPK4sKtyYwwaXvsMndhEh6qSTgR zyWkvGPMtEn148CHtirC2dNrnJn1lfN8UsXkmGG27Ddly5SZ7Ort9mb3X6o5FUsN egGQsqPmSKq5DrWmo64sCkMeHOmC3F7mljNvX9a1qYj8gYymrf6ycbIDamKMg+8o gaU23RdsYI7Hta6P6JwqsQ1tfT63ssLWwWxmjKCLvLA+vHn+lfam5ZnCYB9XR0Mg +FeMrWlFIA0TMyC3eyGH0vNqzrVVD25/D4Cj7hjl5vzDEgTSnbXE715XsMBpWDUG waALHS5p1PE0sIX/NeRjxPKa/+4dzLhaDirvYHFowuwFUAp4GnMJBg== =h1iT -END PGP SIGNATURE-
Re: Is /etc/rc.boot/ obsolete or not?
Miquel == Miquel van Smoorenburg [EMAIL PROTECTED] writes: Miquel It sounds more like you want a rc.local style directory, Miquel not rc.boot. Miquel But what is so difficult about update-rc.d? It's only one Miquel line in the postinst .. (and one in prerm) It's not difficult at all. But I'm just saying rc.boot doesn't need to go away, as sometimes there's really no need for update-rc.d at all. Why make things more complicated than they have to be? Never got around to this one, sorry. It is important to use update-rc.d and not directly place a file in /etc/rcS.d, since a package like file-rc replaces update-rc.d with a different program and does not look in /etc/rcS.d (if I recall correctly). Placing a program there could hose someone's system. The correct way to do it is to place the program in /etc/init.d and use update-rc.d. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: weekly policy summary
retitle 32448 [ACCEPTED 1999/07/18] Policy should use /etc/rcS.d instead of /etc/rc.boot severity 32448 normal forwarded 32448 debian-policy@lists.debian.org thanks Policy still suggests /etc/rc.boot instead of /etc/rcS.d (#32448) * Under discussion. * Proposed on 26 Jan 1999 by Brian Servis; seconded by Julian Gilbey and Joey Hess. * Change policy to refer to /etc/rcS.d instead of the old /etc/rc.boot/ So this seems to be agreed upon; I'm marking it as accepted because it was seconded so long ago. If anyone objects and wants it to sit in an amendment phase for two weeks first, let me know. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Bug#40766: PROPOSED] Rewrite of Configuration files section
A few questions on the wording of this, but once those are clarified,
I will second the proposal.
4.7.1. Definitions
--
configuration file
A file that affects the operation of program, or provides site-
or host-specific information, or otherwise customizes the
behavior of program. Typically, configuration files are intended
to be modified by the system administrator (if needed or desired)
to conform to local policy or provide more useful site-specific
behavior.
conffile
A file listed in a package's `conffiles' file, and is treated
specially by dpkg (See the _Debian Packaging Manual_).
The distinction between these two is important; they are not
interchangeable concepts. Almost all conffiles are configuration
files, but many configuration files are not conffiles.
Note that a script that embeds configuration information (such as most
of the files in `/etc/init.d' and `/etc/cron.{hourly,weekly,monthly}')
is de-facto a configuration file and should be treated as such.
Do you know of any conffiles which are not configuration files? The
concept of a conffile which is not a configuration file is bizarre.
I think that either the definition of configuration file should be
expanded to include conffiles or your 4.7.3 should be expanded to
include references to conffiles. Maybe something like the following
wording could be better?
- The distinction between these two is important; they are not
- interchangeable concepts. Almost all conffiles are configuration
- files, but many configuration files are not conffiles.
+ The distinction between these two is important; they are not
+ interchangeable concepts. Every conffile is considered to be a
+ configuration file, but many configuration files are not conffiles.
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Bug#40767: PROPOSED] wording cleanup w.r.t. conffile/configuration file
Seconded. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Processed: Re: weekly policy summary
Processing commands for [EMAIL PROTECTED]: retitle 32448 [ACCEPTED 1999/07/18] Policy should use /etc/rcS.d instead of /etc/rc.boot Bug#32448: [PROPOSED] Policy should suggest /etc/rcS.d instead of /etc/rc.boot Changed bug title. severity 32448 normal Bug#32448: [ACCEPTED 1999/07/18] Policy should use /etc/rcS.d instead of /etc/rc.boot Bug#32449: Section 3.3.4 (/etc/rc.boot) of policy needs updating Severity set to `normal'. forwarded 32448 debian-policy@lists.debian.org Bug#32448: [ACCEPTED 1999/07/18] Policy should use /etc/rcS.d instead of /etc/rc.boot Bug#32449: Section 3.3.4 (/etc/rc.boot) of policy needs updating Noted your statement that bug has been forwarded to [EMAIL PROTECTED] thanks Stopping processing here. Please contact me if you need assistance. Ian Jackson (administrator, Debian bugs database)
Bug#41547: [PROPOSAL] Correct section 3.3 to take account of file-rc
Package: debian-policy Version: 3.0.0.0 Severity: wishlist Section 3.3 currently makes reference to /etc/rc?.d as containing symlinks to the scripts in /etc/init.d, and a detailed description of how init uses them. It goes on, in section 3.3.3, to say: A program is provided, `update-rc.d', to make it easier for package maintainers to arrange for the proper creation and removal of `/etc/rcn.d' symbolic links from their `postinst' and `postrm' scripts. which implicitly allows the maintainer to create their own symlinks manually. However, in the light of Joey's file-rc package, this section of policy ought to be reworded to make it absolutely clear (and it hasn't been recently) that the description of the /etc/rc?.d directories in section 3.3.1 is only what is used when the standard setup is being used, and that the *only* permissible way to create the symlinks is to use update-rc.d, as the symlinks don't make any sense when file-rc is being used. I will propose a detailed rewriting if initial interest is shown in this proposal. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg
Re: Debian conflicts with FHS on /usr/include/{linux,asm}
On Tue, Jul 13, 1999 at 10:15:42AM -0700, Joseph Carter wrote: Personally I think /usr/src/linux should GO AWAY. Every sysadmin worth their salt uses /usr/src/linux-version or similar with a symlink pointing back for compatibility. It's only common sense that you don't throw away the old software until you've tested the new--especially at the system and kernel levels. If you want to get picky, the admin has no business installing sources directly into /usr/src, being a vendor-controlled area. I keep my kernel source in /usr/local/src/linux-2.2 and linux-2.3. Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome. pgpXMCcFEyxC6.pgp Description: PGP signature
Re: Data section (#38902)
On Fri, Jul 16, 1999 at 02:35:04PM -0700, Joey Hess wrote: Data section (#38902) * Proposed on 3 Jun 1999 by Darren O. Benham; seconded by Peter S Galbraith, Peter Makholm and Peter Makholm. I hate to say this but I think my involvment in this proposal is cursed. In the beginning I didn't appear in the weekly catchup and now my name appears twice. -- I congratulate you. Happy goldfish bowl to you, to me, to everyone, and may each of you fry in hell forever. -- Isaac Asimov, The Dead Past
Bug#40766: PROPOSED] Rewrite of Configuration files section
On Sun, Jul 18, 1999 at 02:45:04AM +0100, Julian Gilbey wrote: Do you know of any conffiles which are not configuration files? The concept of a conffile which is not a configuration file is bizarre. /etc/init.d/* and /etc/cron.d/* are not really configuration files for the programs in the package. (They are configuration files for the system, so it's a bit confusing). They're definately conffiles, though, unless otherwise managed. Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Bug#40766: Rewrite of configuration files section
On Sun, Jul 18, 1999 at 12:44:17PM +0200, Stefan Gybas wrote: So if this update-inetd program modifies a conffile, I am not allowed to call it from my postinst? What's the reason for such a program then? inetd.conf is _not_ a conffile. Actually, dpkg does not know about it at all: [9:16pm] [EMAIL PROTECTED]:~ dpkg -S inetd.conf debmake: /usr/lib/deb-make/debian/inetd.conf.ex netbase: /usr/man/man5/inetd.conf.5.gz netbase is providing a tool to manage this configuration file, instead of making it a conffile. This looks like the only clean solution would be to provide update-* programs and not to mark the configuration files as conffiles. But this means that update-* programs should not modify conffiles at all. That's correct. update-* programs should not modify conffiles. Also, those configuration files should not be provided in the .deb, as dpkg will overwrite them on upgrades. inetd.conf, exim.conf etc are not included in any .deb file. Hamish -- Hamish Moffatt VK3SB (ex-VK3TYD). CCs of replies from mailing lists are welcome.
Bug#40706: Programs that need to access every doc in the system.
Programs which need to refer to all Debian docs should then still be pointing to /usr/doc, until the migration is nearly complete. I'm talking about apache ( /doc/ ), dhelp, etc.
Bug#40766: Rewrite of configuration files section
Hamish Moffatt wrote: inetd.conf is _not_ a conffile. Ok, now I understand. In a previous mail you once wrote conffile when you probably meant configuration file which is not a conffile and this was causing somy of my confusion. Sorry for this! -- Stefan Gybas
Bug#40766: Rewrite of configuration files section
Steve Greenland wrote: What Hamish was pointing out is that it's okay to use emacs or vi or icepref to modify configuration files and even conffiles. The policy proposal was in no way meant to imply that you can't write programs to modify conffiles (either general or specific), just that they can't be used in a way that hides what they are doing. This is probably obvious to most people, which is why saying anything about it tends to be confusing. From reading your proposal (and the original policy text) I got the impression that such tools would not be allowed. I'm also the maintainer of Linuxconf (which is obviously such a tool) and someone on debian-admintool once claimed that Linuxconf was violating policy because it changes conffiles of other packages. So I would like to see a section like this one from your other mail added to our proposal: It's ok to have a special/specialized editor to modify a conffile, but it should never be run by anything except a human, and it should be obvious to that human that the conffile is being modified. BTW, both this proposal (#40766) and the general clean-up proposal (#40767) are currently stalled with only one official seconder (Joey Hess). I second both proposals. -- Stefan Gybas
Bug#40766: PROPOSED] Rewrite of Configuration files section
On 17-Jul-99, 20:45 (CDT), Julian Gilbey [EMAIL PROTECTED] wrote:
Note that a script that embeds configuration information (such as most
of the files in `/etc/init.d' and `/etc/cron.{hourly,weekly,monthly}')
is de-facto a configuration file and should be treated as such.
Do you know of any conffiles which are not configuration files? The
concept of a conffile which is not a configuration file is bizarre.
I think that either the definition of configuration file should be
expanded to include conffiles or your 4.7.3 should be expanded to
include references to conffiles.
The reasoning here is that a conffile is file that dpkg handles in a
special way (avoiding overwriting system-specific changes). That special
way is most often appropriate for configuration files, but there is
no technical reason it couldn't be used for non-configuration files
if that behavior is useful. Examples? Well, I don't really think of
the /etc/init.d startup scripts as configuration files in any purest
sense; they are more acurately described as scripts subject to local
modification (which I personally would prefer be modified to store the
configuration data (including whether or not the daemon was actually to
be started) somewhere else, leaving the actual init script unmodified).
Of course, I'm the one who put in the statement that init.d scripts are
de-facto a configuration file; I appear to be conflicted about this
topic.
I'm against saying that every conffile is a configuration file simply
because I don't want to lock out some other legitimate use of the
conffile mechanism.
Steve
