Re: How to handle conffiles when renaming or splitting a package?
On 2021-01-03 09:02 +0900, Charles Plessy wrote:
> I have recently split the mime-support package in two: media-types and
> mailcap. But I wonder if I handled the conffiles correctly.
>
> mime-support had the conffiles `/etc/mime.types` and
> `/etc/mailcap.order` until version 3.64. Version 3.65 is a transitional
> package containing only a changelog and a copyright file, and depends on
> media-types and mailcap. And these two packages declare a Breaks and
> Replaces relationship against mime-support << 3.65.
>
> As a result of the upgrade, the conffiles are now owned by the new
> packages. But dpkg still keeps a record that the mime-support has
> the "obsolete" version of them:
>
> # dpkg-query -W -f='${Conffiles}\n' media-types
> /etc/mime.types 43fa90aa9a5e009997f451be169ac530
>
> # md5sum /etc/mime.types
> 43fa90aa9a5e009997f451be169ac530 /etc/mime.types
>
> # dpkg-query -W -f='${Conffiles}\n' mailcap
> /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e
>
> # dpkg-query -W -f='${Conffiles}\n' mime-support
> /etc/mime.types 0d516753aee0a2c670c79667aad0c836 obsolete
> /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e obsolete
>
> I have received reports from users who consider this a problem. Indeed,
> in the case of mailcap it is potentially confusing as the conffile's MD5
> sum has not changed.
>
> On the other hand, once mime-support is purged, which is how
> transitionnal packages eventually should be handled, the situation is
> clean. So I am not sure if there is a problem here.
>
> Is it needed to clean dpkg's database so that it does not report
> obsolete conffiles for mime-support? (Actually, I would have expected
> dpkg to do this automagically given the Breaks and Replaces
> relationship.)
Looks like you have hit #886389[1] in dpkg, I don't think you can do
anything about it in your packages.
Cheers,
Sven
1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886389
How to handle conffiles when renaming or splitting a package?
Hello everybody,
and happy new year !
I have recently split the mime-support package in two: media-types and
mailcap. But I wonder if I handled the conffiles correctly.
mime-support had the conffiles `/etc/mime.types` and
`/etc/mailcap.order` until version 3.64. Version 3.65 is a transitional
package containing only a changelog and a copyright file, and depends on
media-types and mailcap. And these two packages declare a Breaks and
Replaces relationship against mime-support << 3.65.
As a result of the upgrade, the conffiles are now owned by the new
packages. But dpkg still keeps a record that the mime-support has
the "obsolete" version of them:
# dpkg-query -W -f='${Conffiles}\n' media-types
/etc/mime.types 43fa90aa9a5e009997f451be169ac530
# md5sum /etc/mime.types
43fa90aa9a5e009997f451be169ac530 /etc/mime.types
# dpkg-query -W -f='${Conffiles}\n' mailcap
/etc/mailcap.order ba07e08a7fe3741d0b8339127963190e
# dpkg-query -W -f='${Conffiles}\n' mime-support
/etc/mime.types 0d516753aee0a2c670c79667aad0c836 obsolete
/etc/mailcap.order ba07e08a7fe3741d0b8339127963190e obsolete
I have received reports from users who consider this a problem. Indeed,
in the case of mailcap it is potentially confusing as the conffile's MD5
sum has not changed.
On the other hand, once mime-support is purged, which is how
transitionnal packages eventually should be handled, the situation is
clean. So I am not sure if there is a problem here.
Is it needed to clean dpkg's database so that it does not report
obsolete conffiles for mime-support? (Actually, I would have expected
dpkg to do this automagically given the Breaks and Replaces
relationship.)
Have a nice day,
Charles
--
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work, https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy
Re: Help with removal of conffiles
Hi, >However, after reading the manpage for dh_installdeb [4] (more >specifically, the section `package.maintscript', I changed my mind and >added lines such as: > > rm_conffile /etc/bash_completion.d/harbour 1:2.8-5~ > >So... Is that the right thing to do? I.e. regardless of the version >at which a conffile was removed, I should use the current release >version in `rm_conffile' calls? This is explicitly answered in [3] under prior-version: If the conffile has not been shipped for several versions, and you are now modifying the maintainer scripts to clean up the obsolete file, prior-version should be based on the version of the package that you are now preparing, not the first version of the package that lacked the conffile. This applies to all other actions in the same way. -nik >[3] >https://manpages.debian.org/unstable/dpkg/dpkg-maintscript-helper.1.en.html
Help with removal of conffiles
Hi, mentors, I need help with the removal of obsolete conffiles in bash-completion. I think I understood what to do, but since I don't know how to reproduce the problem, I'm uncomfortable with the change. Below, I give a long description of the problem (feel free to skip it if it sounds trivial), then I ask the question itself. * Description of the problem: Bug report #645439 [1] for bash-completion shows that some conffiles have been removed from the package, but never purged from users' systems (apart from the conffiles listed in the bug report, I found two other files). In order to learn about conffiles and what package maintainers need to do in their packages to properly handle them (deletion, updates, installation), I read the wiki about conffile handling in dpkg [2], as well as the documentation for dpkg-maintscript-helper [3], and dh_installdeb [4]. Finally, I read the relevant commits in the repository for the bash-completion package [5], to try and understand what has already been done regarding the removal of obsolete conffiles, and I found this particular commit [6], which adds debian/maintscript. Since bash-completion 2.0 (actually 1.90), the completion files where moved from /etc/bash_completion.d to /usr/share/bash-completion, which rendered a lot of conffiles obsolete. The commit above deals with these files, but only with the files that were present in the 1.3-x releases. Files that have been previously removed (such as those reported in debian bug report #645439 [1]) have never been dealt with, thus causing the bug. * Actual question: Now, I'm planning to add the remaining files (which I tracked down by examining the history of the repository) to maintscript, but I'm uncertain about the syntax. Initially, I thought I should add lines such as: rm_conffile /etc/bash_completion.d/harbour 1:1.1-1 for conffiles removed in bash-completion version 1:1.1-1. However, after reading the manpage for dh_installdeb [4] (more specifically, the section `package.maintscript', I changed my mind and added lines such as: rm_conffile /etc/bash_completion.d/harbour 1:2.8-5~ So... Is that the right thing to do? I.e. regardless of the version at which a conffile was removed, I should use the current release version in `rm_conffile' calls? The changes that I'm planning to do are implemented in a staging-area in the repository by some commits (one for each version that removed a conffile) [7,8,9,10]. (you are free to check them if that helps) Thank you very much for your patience in reading up until this point! :) Kind regards, Gabriel [1] https://bugs.debian.org/645439 [2] https://wiki.debian.org/DpkgConffileHandling [3] https://manpages.debian.org/unstable/dpkg/dpkg-maintscript-helper.1.en.html [4] https://manpages.debian.org/unstable/debhelper/dh_installdeb.1.en.html [5] https://salsa.debian.org/debian/bash-completion/tree/conffiles [6] https://salsa.debian.org/debian/bash-completion/commit/0c22c4ac451d3195da4806728c6ed1163ab88008 [7] https://salsa.debian.org/debian/bash-completion/commit/c9203c53ea75d6fe708bf2deb82f1341072a97db [8] https://salsa.debian.org/debian/bash-completion/commit/e55d81a56ae89ee0b9cd3bc1e6fc683a33c17991 [9] https://salsa.debian.org/debian/bash-completion/commit/7d413831f1a8ac1181f21efdae594fc8ac5ec0f3 [10] https://salsa.debian.org/debian/bash-completion/commit/2c23594b23c00a663e396d185922e577881e7d16
Re: Fwd: Re: Adequate reports obsolete conffiles: and now what?
Hi, >OK, I see your point. > >In my usual, provocative style: To me, this means that the bug should be >closed without further actions unless there is more input. or change to usr/share, that seems a saner approach. Your call, I don't have an opinion here! G.
Re: Fwd: Re: Adequate reports obsolete conffiles: and now what?
On 23/01/17 18:03, Gianfranco Costamagna wrote: hello, Hi! However I think the .dist files should be installed in /usr/share and copied from there instead of being installed in /etc. This is of course the Right Thing to do. Will implement, thanks! This is nice, however I think this "workaround" should be dropped post-Stretch release. Right now living for an year or two with such conf files, will make people switch to the new lirc, so an adequate report is not so much a problem to my eyes, and will remember us to drop the hack at some point :p OK, I see your point. In my usual, provocative style: To me, this means that the bug should be closed without further actions unless there is more input. Just to be clear ;) --alec
Re: Fwd: Re: Adequate reports obsolete conffiles: and now what?
hello, >> However I think the .dist files >> should be installed in /usr/share and copied from there instead of being >> installed in /etc. > >This is of course the Right Thing to do. Will implement, thanks! This is nice, however I think this "workaround" should be dropped post-Stretch release. Right now living for an year or two with such conf files, will make people switch to the new lirc, so an adequate report is not so much a problem to my eyes, and will remember us to drop the hack at some point :p cheers, G.
Fwd: Re: Adequate reports obsolete conffiles: and now what?
oops, happened to send the reply to James as a PM... here it comes, it was actually meant for the list Forwarded Message Subject: Re: Adequate reports obsolete conffiles: and now what? Date: Sat, 21 Jan 2017 16:40:10 +0100 From: Alec Leamas <leamas.a...@gmail.com> To: James Cowgill <jcowg...@debian.org> On 21/01/17 13:16, James Cowgill wrote: Hi, Hi, thanks for taking time to reply! By definition, an obsolete conffile is a file which used to be a conffile, isn't in a new package version, but wasn't moved/removed on upgrade. So, when I have done such an operation on purpose, the warning is sort a false positive, right? Removing a conffile with dpkg-maintscript-helper will actually move it (to xxx.dpkg-back) if it was modified, so I think you can safely remove this as users will still be able to refer to it later. Well... I have made both manual instructions and a script based on that hardware.conf is still in it's original location. Of course, the file should eventually be removed, but doesn't it make make sense to leave it in it's original location for the first update cycle(s)? Basically, having it in it's original location IMHO makes it much more visible. Or? Isn't this the problem conffiles was meant to solve? Dpkg will ask the user before updating those config files and not touching them is the default option. This will also warn the user when they may need to update them anyway (eg new features). I guess this is a maintainer decision on how they want to do this (even if I think it's a bad idea) so using .dist files is still OK. Yes...the lirc history is plagued with some bugs related to this. I'm not saying that following this scheme is the ultimate solution, but for better or worse it's a decision I have made. In this case, and as long as you're sure your maintainer scripts always do the right thing, you can ignore adequate. OK... But "being sure that the maintainer scripts does the right thing" is not something I feel comfortable with. The conffiles handling is hard to understand for anyone; it's even harder for me with a RPM background ;) However I think the .dist files should be installed in /usr/share and copied from there instead of being installed in /etc. This is of course the Right Thing to do. Will implement, thanks! Cheers! --alec
Re: Adequate reports obsolete conffiles: and now what?
Hi, On 21/01/17 09:51, Alec Leamas wrote: > The new, shiny lirc 0.9.4 has received a bug report #851618. At the > core, this is about adequate reporting > > lirc: obsolete-conffile /etc/lirc/irexec.lircrc > lirc: obsolete-conffile /etc/lirc/lircmd.conf > lirc: obsolete-conffile /etc/lirc/hardware.conf > lirc: obsolete-conffile /etc/lirc/lircd.conf > lirc: obsolete-conffile /etc/lirc/lirc_options.conf > > However, all of these files exists for a purpose and are not obsolete. By definition, an obsolete conffile is a file which used to be a conffile, isn't in a new package version, but wasn't moved/removed on upgrade. > The details: > > - hardware.conf is indeed obsolete in 0.9.4. However, the manual, > breaking update is about moving bits and pieces from hardware,conf to > other files, so it needs to be around for some cycles before it's removed. Removing a conffile with dpkg-maintscript-helper will actually move it (to xxx.dpkg-back) if it was modified, so I think you can safely remove this as users will still be able to refer to it later. > - For the other files I'm using my own scheme: The upstream files are > installed as e. g.,lirc_options.conf.dist. This file is updated but not > used. If the actually used lirc_options.conf is missing it's created as > a copy of the *dist file, but otherwise kept as-is.. In other words, I > don't try to merge possible upstream changes, I just keep the *dist > files around as reference Isn't this the problem conffiles was meant to solve? Dpkg will ask the user before updating those config files and not touching them is the default option. This will also warn the user when they may need to update them anyway (eg new features). I guess this is a maintainer decision on how they want to do this (even if I think it's a bad idea) so using .dist files is still OK. In this case, and as long as you're sure your maintainer scripts always do the right thing, you can ignore adequate. However I think the .dist files should be installed in /usr/share and copied from there instead of being installed in /etc. Presumably these .dist files have been (incorrectly) marked as conffiles already? > Since the overall idea is that the adequate (or really dpkg) error > message is a bug: How should I resolve this bug? James signature.asc Description: OpenPGP digital signature
Adequate reports obsolete conffiles: and now what?
Dear list, The new, shiny lirc 0.9.4 has received a bug report #851618. At the core, this is about adequate reporting lirc: obsolete-conffile /etc/lirc/irexec.lircrc lirc: obsolete-conffile /etc/lirc/lircmd.conf lirc: obsolete-conffile /etc/lirc/hardware.conf lirc: obsolete-conffile /etc/lirc/lircd.conf lirc: obsolete-conffile /etc/lirc/lirc_options.conf However, all of these files exists for a purpose and are not obsolete. The details: - hardware.conf is indeed obsolete in 0.9.4. However, the manual, breaking update is about moving bits and pieces from hardware,conf to other files, so it needs to be around for some cycles before it's removed. - For the other files I'm using my own scheme: The upstream files are installed as e. g.,lirc_options.conf.dist. This file is updated but not used. If the actually used lirc_options.conf is missing it's created as a copy of the *dist file, but otherwise kept as-is.. In other words, I don't try to merge possible upstream changes, I just keep the *dist files around as reference Since the overall idea is that the adequate (or really dpkg) error message is a bug: How should I resolve this bug? Any clue out there? Shortcut to the packaging at [1] --alec [1] https://sourceforge.net/p/lirc/git/ci/debian/tree/debian/
Re: Cleaning up obsolete conffiles
Paul Wise wrote:
Bob Proulx wrote:
How can I as a system administrator clean that obsolete conffile up?
rm -f /etc/some-obsolete-conffile
apt-get --reinstall install package-that-provided-the-obsolete-conffile
Ah! Thanks. That works.
I have many obsolete conffiles on my system.
Please file bugs about obsolete conffiles when you find new ones. The
packages themselves should clean up their obsolete conffiles.
I am cleaning up Squeeze systems before upgrading. But even Wheezy
and Sid have many. This is on my updated Sid system.
$ dpkg-query -W -f='${Conffiles}\n' | awk '$NF==obsolete{print$1}' | xargs
-L1 dlocate | awk -F: '{print$1}' | sort -u | wc -l
26
But it has been upgraded through many releases.. I don't know if
these are still a problem in recent versions or if these have been
hanging around since previous releases. I will clean up my Squeeze
machines and upgrade them to Wheezy. Then any obsolete conffiles left
will be current issues and can be filed.
To help with this task, you can install the package called
'adequate' and enable the post-install debconf prompt.
Thanks for that pointer. I will try it.
But of course many packages are difficult to purge.
Every package must be possible to purge, if it is not possible then it
is a release-critical issue and you should file a severity serious bug
against the package.
I didn't say impossible. I said difficult. There are dependencies
that cause a large cone to be removed. And then there are essential
packages. I am still trying to use the system at the same time.
$ sudo apt-get purge bash
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
bash-static
The following packages will be REMOVED:
bash* bash-completion* bashdb* common-lisp-controller* devscripts-el*
dpatch* emacs-goodies-el* foomatic-db-engine* foomatic-filters* lsb*
lsb-printing*
python-foomatic*
The following NEW packages will be installed:
bash-static
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
bash
0 upgraded, 1 newly installed, 12 to remove and 203 not upgraded.
Need to get 937 kB of archives.
After this operation, 9,134 kB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
?]
Thanks!
Bob
P.S. Here is my list on my Sid machine.
$ dpkg-query -W -f='${Conffiles}\n' | awk '$NF==obsolete{print$1}' | xargs
-L1 dlocate | awk -F: '{print$1}' |
sort -u
asciidoc
base-files
bash-completion
bashdb
chromium-browser
cvs
epiphany-browser-data
firebird2.5-common
gimp-data
gnome-panel-data
gsfonts
iceweasel
lightdm
lsb-core
mailgraph
setserial
shorewall
shorewall6
smartmontools
source-highlight
stunnel4
subversion-tools
ttf-arphic-uming
vlc-data
w3c-markup-validator
xserver-xorg-video-intel
signature.asc
Description: Digital signature
Re: Cleaning up obsolete conffiles
Paul Wise wrote:
Please file bugs about obsolete conffiles when you find new ones. The
packages themselves should clean up their obsolete conffiles.
Is there a bug example or two you could point me to so that I can
follow the standard template of reporting these problems? It appears
I have some bug reports to file against packages in Wheezy.
Bob
dpkg-query -W -f='${Conffiles}\n' | awk '$NF==obsolete{print$1}' | xargs -L1
dlocate | awk -F: '{print$1}' | sort -u
bind9
grub-pc
hdparm
initscripts
libgtk2.0-0
munin
mysql-server-5.1
netbase
resolvconf
rubygems1.8
shorewall
signature.asc
Description: Digital signature
Re: Cleaning up obsolete conffiles
On Thu, May 9, 2013 at 4:07 PM, Bob Proulx wrote:
Is there a bug example or two you could point me to so that I can
follow the standard template of reporting these problems? It appears
I have some bug reports to file against packages in Wheezy.
Here is a recent example of one I filed:
http://bugs.debian.org/706911
And my template for that:
Subject:conffiles not removed
Usertags: conffile
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate
The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by dh_installdeb
to remove these obsolete conffiles on upgrade.
http://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
http://manpages.debian.net/man/1/dh_installdeb
This bug report brought to you by adequate:
http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/
pkg=
adequate $pkg
dpkg-query -W -f='${Conffiles}\n' $pkg | grep obsolete
dpkg -L $pkg | sort -u | grep /etc 1
dpkg-deb --contents /var/cache/apt/archives/$pkg_*.deb | sed
's/^.*\.\//\//;s_/$__' | sort -u | grep /etc 2
diff -u 1 2
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAKTje6E8xJ7ZApFpgH66G-1vkGFK__S=vda67l4yt5n_dqr...@mail.gmail.com
Re: Cleaning up obsolete conffiles
On Thu, May 09, 2013 at 01:49:48PM +0800, Paul Wise wrote: On Thu, May 9, 2013 at 1:08 PM, Bob Proulx wrote: But of course many packages are difficult to purge. Every package must be possible to purge, if it is not possible then it is a release-critical issue and you should file a severity serious bug against the package. Packages that mess with /etc/skel: * bash * base-files So ok, let's purge them. And dpkg for added fun :) -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130509121416.gb21...@angband.pl
Cleaning up obsolete conffiles
I have many obsolete conffiles on my system. It has been upgraded
through many releases.
dpkg-query -W -f='${Conffiles}\n' | grep obsolete
Picking a simple one as an example:
/etc/skel/.bash_profile d1a8c44e7dd1bed2f3e75d1343b6e4e1 obsolete
If I purge the package and install it fresh then that file will not be
there and it will not be listed as an obsolete conffile. But of
course many packages are difficult to purge.
How can I as a system administrator clean that obsolete conffile up?
I can certainly rm -f the file. But afterward it is still listed in
dpkg as an obsolete conffile even though the file was removed.
Is there a method to clean these up, remove them from the disk, and
tell dpkg that they are no longer there? I have searched but I have
not found a way to do this.
Thanks,
Bob
signature.asc
Description: Digital signature
Re: Cleaning up obsolete conffiles
On Thu, May 9, 2013 at 1:08 PM, Bob Proulx wrote: I have many obsolete conffiles on my system. Please file bugs about obsolete conffiles when you find new ones. The packages themselves should clean up their obsolete conffiles. To help with this task, you can install the package called 'adequate' and enable the post-install debconf prompt. But of course many packages are difficult to purge. Every package must be possible to purge, if it is not possible then it is a release-critical issue and you should file a severity serious bug against the package. How can I as a system administrator clean that obsolete conffile up? rm -f /etc/some-obsolete-conffile apt-get --reinstall install package-that-provided-the-obsolete-conffile -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6h5ckk8j2e6qnmfy34irpwaz24ok+7vsroaddusm6f...@mail.gmail.com
Re: Transitional packages: unmark auto, dealing with conffiles
Am 24.12.2011 12:23, schrieb David Kalnischkies: It's not only aptitude, every package manager using libapt will hate you for this - and therefore i will hate you; even on Christmas. ;) I wouldn't want you to hate me. At least not on Christmas. ;-) In general, you should NEVER touch a file belonging to another package as you never know if it will be there and which format it has -- and for /var/lib files is this especially true as they are state files. I agree that modifying other packages' files is a bad idea. That's why I called it a hack. My hope was that someone could show me a clean, policy-consistent way to solve the problems I encountered when trying to provide a transitional package. I have found the interesting thread 'Transitional (dummy) packages considered silly' on Debian Devel (http://lists.debian.org/debian-devel/2009/09/msg00687.html). Will any of the suggestions made there make it into Debian? E.g., how about a new control field 'Superseeds'? Have you read some of the responses? Looks like you haven't as a few counterarguments are given in this thread like blocking the old name even longer, could allow social fights like chromium superseeds iceweasel or kde superseeds gnome and in general allows any maintainer to install his package without direct user interaction. Let's just assume that we both have read the whole thread ;-). I guess how one weighs the different arguments heavily depends on one's own background and preferences. My impression was that most posters eventually liked the ideas of a superseeds relationship. But by no means would I claim to know what the Debian policy on transitional packages should look like. I'm just a spare time package maintainer trying to entice the Debian gods to come up with a solution. One reason why I like Debian is that it tries to do things the right way. To me, that includes making things explicit and documenting them in the policy. If a package management use case requires using scarcely documented features or even hacking, then I'm confident the Debian community can up with a better solution. I think, the existing approach to transitional packages involves too many implicit solutions, e.g. using special sections or relying on keywords in a package's description. It would be great if the support provided by apt could be reviewed, potentially extended, documented in the Debian policy and the wiki, and adopted by all package mamangement tools. If you think that is too unlikely, think about situations in which a program changes drastically from v1 to v2 and a fork tries to maintain v1. Does this fork now superseed v1 of the program or is it v2 ? (e.g. amarok vs. clementine or in the old thread apache vs apache2) Also, what should be done if two packages claim to superseed the same package? And what happens if a rename is reverted? Or the next stable release carries a new package with the superseeded name, thinking e.g. about the git: gnuit vs git-core name-collision. Also, think about an application which changes his program name, but to allow a soft transition, the transistional package provides a wrapper with the old name. Clearly the new superseeds the old, but removing the old still removes functionality… It seems to me that potential solutions to some of your caveats were suggested in the original thread. And no package maintainer would be forced to use the superseeds relationship. What has worked in the past does not have to be changed. But we might have to ask: How do we handle these cases now? And if a policy extension could solve some of the existing problems (e.g. auto install bit tansfer, configuration file transition), would it introduce bigger problems elsewhere? We can't prevent misuse, though. I don't need a superseeds relationship to create havoc. E.g., I could simply modify other package's files... ;-) Let's just try to find the best overall solution. Should it include a superseeds relationship? I don't know. Way to complex for such a small usecase in my eyes. Properly better to invest the time to make disappearing packages policy-compatible and usable instead. In the easy cases libapt users even transfer the auto-bit to the replacer… Well, why not do both? Malte -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f097f7a.4010...@berlin.de
Re: Transitional packages: unmark auto, dealing with conffiles
On Mon, Dec 19, 2011 at 22:08, Malte Forkel malte.for...@berlin.de wrote: Lenny? I have tested clearing the flag in '/var/lib/apt/extended_state' from the postinst script of the transitional package. But aptitude will override this by setting the flag later during the upgrade. And its a hack, anyway. It's not only aptitude, every package manager using libapt will hate you for this - and therefore i will hate you; even on Christmas. ;) In general, you should NEVER touch a file belonging to another package as you never know if it will be there and which format it has -- and for /var/lib files is this especially true as they are state files. Regarding Lenny: Just don't care anymore. Security support ends in due time, so don't try to support unsupported channels. Users of these old systems will have bigger problems than the inability to install your package (and that's not even the problem you seem to deal with…). If you really really really have to do it, just copy the relevant code from the helpers, they aren't magic after all, but make sure to test it carefully! Regarding the configuration files, I know now that newer versions of dpkg include 'dpkg-maintscript-helper' with commands to move or remove conffiles. This works nicely in Squeeze. But again, how can I support systems with Lenny? In order to make the transitional package forget about a conffile, I tested removing it in the package's postinst script and also remove the corresponding entry from /var/lib/dpkg/info/package.list. That seems to work, but I would consider it a hack as well. Same comment regarding lenny. Same about file-edit hacks. Add a realworld example to this as dpkg will change info/ filenames (for at least some packages) with the introduction of multiarch. I have found the interesting thread 'Transitional (dummy) packages considered silly' on Debian Devel (http://lists.debian.org/debian-devel/2009/09/msg00687.html). Will any of the suggestions made there make it into Debian? E.g., how about a new control field 'Superseeds'? Have you read some of the responses? Looks like you haven't as a few counterarguments are given in this thread like blocking the old name even longer, could allow social fights like chromium superseeds iceweasel or kde superseeds gnome and in general allows any maintainer to install his package without direct user interaction. If you think that is too unlikely, think about situations in which a program changes drastically from v1 to v2 and a fork tries to maintain v1. Does this fork now superseed v1 of the program or is it v2 ? (e.g. amarok vs. clementine or in the old thread apache vs apache2) Also, what should be done if two packages claim to superseed the same package? And what happens if a rename is reverted? Or the next stable release carries a new package with the superseeded name, thinking e.g. about the git: gnuit vs git-core name-collision. Also, think about an application which changes his program name, but to allow a soft transition, the transistional package provides a wrapper with the old name. Clearly the new superseeds the old, but removing the old still removes functionality… Way to complex for such a small usecase in my eyes. Properly better to invest the time to make disappearing packages policy-compatible and usable instead. In the easy cases libapt users even transfer the auto-bit to the replacer… Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caaz6_fc-xbwqnbdewnsqfpb4pbq5udtpeqcijjyyv76feih...@mail.gmail.com
Transitional packages: unmark auto, dealing with conffiles
Hello, I am writing a transitional package to handle a software name change. There are two problems I'm trying to handle: - How to avoid marking the new package (which the transitional package depends upon) as being autoinstalled. - How to deal with old conffiles not adopted by the new package. I have posed these two questions before, one on Debian User (http://lists.debian.org/debian-user/2011/12/msg00739.html), one on Debian Devel (http://lists.debian.org/debian-devel/2011/12/msg00337.html). In both cases, I have received helpful advice and the suggestion to pose these questions on Debian Mentors. So I'll recap what I have learned so far and hope you can fill in the mising pieces. Regarding the unmark auto flag, I know now that newer versions of apt will not mark packages as auto if they are autoinstalled due to a package in section 'oldlibs' or 'metapackages'. So, if the transitional package belongs to one of those two and gets installed by 'apt-get dist-upgrade' in Squeeze, everything is fine. But what if another tool is used, e.g. aptitude. And how can I support people still running Lenny? I have tested clearing the flag in '/var/lib/apt/extended_state' from the postinst script of the transitional package. But aptitude will override this by setting the flag later during the upgrade. And its a hack, anyway. Regarding the configuration files, I know now that newer versions of dpkg include 'dpkg-maintscript-helper' with commands to move or remove conffiles. This works nicely in Squeeze. But again, how can I support systems with Lenny? In order to make the transitional package forget about a conffile, I tested removing it in the package's postinst script and also remove the corresponding entry from /var/lib/dpkg/info/package.list. That seems to work, but I would consider it a hack as well. I have found the interesting thread 'Transitional (dummy) packages considered silly' on Debian Devel (http://lists.debian.org/debian-devel/2009/09/msg00687.html). Will any of the suggestions made there make it into Debian? E.g., how about a new control field 'Superseeds'? There are probably more questions regarding transitional packages than the two I have come across so far. It seems to me there could be better support for transitional packages in Debian in terms of policy, tool support and documentation. What are your thoughts? Of course, I'd be happy to help in bringing these issues along. Thanks, Malte -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jco94f$3aj$1...@dough.gmane.org
Re: dpkg status Conffiles obsolete flag?
Ansgar Burchardt wrote: Sven Joachim wrote: Bob Proulx wrote: I am hoping to understand the obsolete flag on conffiles in the dpkg status file. There are many packages that include this flag at the end of the line. For example: [...] They are obsolete because they no longer exist in the package. It is the package maintainer's task to deal with them (e.g. remove them if they are unmodified and no longer needed). Unfortunately, this is often not done. Ah... This makes things clear. I had missed it. When they are no longer shipped in the package that used to contain them; dpkg does not currently remove obsolete conffiles unless that package is purged, see #330256¹. dpkg-maintscript-helper(1) also has a good explanation what happens and why. It also makes dealing with them (in maintainer scripts) easier. Also very useful information. It would seem that packages that have left unmodified obsolete conffiles behind as lint, especially in init.d, are worth a bug report about them. This gets in the way of upgrades such as moving to dependency based booting and from my perspective one of the strongest strengths of Debian is the ability to upgrade. Thanks! Bob signature.asc Description: Digital signature
dpkg status Conffiles obsolete flag?
I am hoping to understand the obsolete flag on conffiles in the dpkg status file. There are many packages that include this flag at the end of the line. For example: Package: file Conffiles: /etc/magic.mime 272913026300e7ae9b5e2d51f138e674 obsolete /etc/magic 272913026300e7ae9b5e2d51f138e674 obsolete And there many more examples such as in apache2.2-common and gsfonts. These conffiles that are marked obsolete do exist on the system. I could not find where this was documented. The man page or dpkg says: /var/lib/dpkg/status Statuses of available packages. This file contains information about whether a package is marked for removing or not, whether it is installed or not, etc. See section INFORMATION ABOUT PACKAGES for more info. But the section INFORMATION ABOUT PACKAGES does not say anything about this field that I could find. I downloaded the source to several packages having obsolete conffiles marked and I could not find any reference in the package that would cause those files to be marked as obsolete. The reason I am looking at this is because I am trying to automate system upgrades from Lenny to Squeeze and some packages have init.d scripts that are marked obsolete and I am trying to understand why. Could some kind soul enlighten me on how conffiles are marked obsolete? Thanks! Bob signature.asc Description: Digital signature
Re: dpkg status Conffiles obsolete flag?
On 2011-07-10 20:55 +0200, Bob Proulx wrote: I am hoping to understand the obsolete flag on conffiles in the dpkg status file. There are many packages that include this flag at the end of the line. For example: Package: file Conffiles: /etc/magic.mime 272913026300e7ae9b5e2d51f138e674 obsolete /etc/magic 272913026300e7ae9b5e2d51f138e674 obsolete And there many more examples such as in apache2.2-common and gsfonts. These conffiles that are marked obsolete do exist on the system. I could not find where this was documented. The man page or dpkg says: /var/lib/dpkg/status Statuses of available packages. This file contains information about whether a package is marked for removing or not, whether it is installed or not, etc. See section INFORMATION ABOUT PACKAGES for more info. But the section INFORMATION ABOUT PACKAGES does not say anything about this field that I could find. I downloaded the source to several packages having obsolete conffiles marked and I could not find any reference in the package that would cause those files to be marked as obsolete. They are obsolete because they no longer exist in the package. It is the package maintainer's task to deal with them (e.g. remove them if they are unmodified and no longer needed). Unfortunately, this is often not done. The reason I am looking at this is because I am trying to automate system upgrades from Lenny to Squeeze and some packages have init.d scripts that are marked obsolete and I am trying to understand why. Could some kind soul enlighten me on how conffiles are marked obsolete? When they are no longer shipped in the package that used to contain them; dpkg does not currently remove obsolete conffiles unless that package is purged, see #330256¹. Cheers, Sven ¹ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=330256 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87box16ht7@turtle.gmx.de
Re: dpkg status Conffiles obsolete flag?
Hi, I am hoping to understand the obsolete flag on conffiles in the dpkg status file. There are many packages that include this flag at the end of the line. For example: [...] They are obsolete because they no longer exist in the package. It is the package maintainer's task to deal with them (e.g. remove them if they are unmodified and no longer needed). Unfortunately, this is often not done. The reason I am looking at this is because I am trying to automate system upgrades from Lenny to Squeeze and some packages have init.d scripts that are marked obsolete and I am trying to understand why. Could some kind soul enlighten me on how conffiles are marked obsolete? When they are no longer shipped in the package that used to contain them; dpkg does not currently remove obsolete conffiles unless that package is purged, see #330256¹. dpkg-maintscript-helper(1) also has a good explanation what happens and why. It also makes dealing with them (in maintainer scripts) easier. Regards, Ansgar -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/851uxxu47b@tsukuyomi.43-1.org
Init scripts as conffiles
I was wondering, why are init scripts installed as conffiles? Is there a good reason other than that they're in /etc and nobody bothered to make an exception in debhelper? I would have thought it would be better to treat them as not to be modified by the user/admin; any init configuration should be done via /etc/default. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110215163325.48f62cc0@toddler
Re: Init scripts as conffiles
On Tue, Feb 15, 2011 at 04:33:25PM +, Tony Houghton wrote:
[...]
I would have thought it would be better to treat them as not to be
modified by the user/admin; any init configuration should be done via
/etc/default.
In years gone by, I've frequently had to manually adjust initscript
contents or symlink ordering to deal with issues. The vast majority
of initscripts don't source variables from under /etc/default, and
those which do often lack variables for things like
overriding/augmenting service start options or defining additional
local service interdependencies. If policy were altered to make
initscripts non-conffiles, tons of packages would be insta-buggy (at
least from a wishlist standpoint, if not worse) due to the loss of
admin flexibility.
Also, trying to change a major class of system controls which have
traditionally been considered conffiles to non-conffile status would
be a near impossibility due to the number of installed systems with
existing local modifications.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110215170537.ge1...@yuggoth.org
Re: Init scripts as conffiles
On Tue, 15 Feb 2011 17:05:41 + The Fungi fu...@yuggoth.org wrote: On Tue, Feb 15, 2011 at 04:33:25PM +, Tony Houghton wrote: [...] I would have thought it would be better to treat them as not to be modified by the user/admin; any init configuration should be done via /etc/default. In years gone by, I've frequently had to manually adjust initscript contents or symlink ordering to deal with issues. The vast majority of initscripts don't source variables from under /etc/default, and those which do often lack variables for things like overriding/augmenting service start options or defining additional local service interdependencies. If policy were altered to make initscripts non-conffiles, tons of packages would be insta-buggy (at least from a wishlist standpoint, if not worse) due to the loss of admin flexibility. Also, trying to change a major class of system controls which have traditionally been considered conffiles to non-conffile status would be a near impossibility due to the number of installed systems with existing local modifications. I'd consider packages which require editing of the init script instead of using /etc/default or similar to be badly designed at best. I know fixing the mass of existing packages would be too big a job, but I thought it might be possible to provide a new option in dh_installdeb and encourage its use for new packages. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110215172739.2c81c...@realh.co.uk
Re: Init scripts as conffiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tony Houghton, 2011-02-15 17:33: I was wondering, why are init scripts installed as conffiles? Debain switched to dependency-based boot with Squeeze and those dependencies are controlled by the LSB headers inside each init script. On the majority of my systems init scripts are modified to reflect individual requirements of services during boot (e.g. openvpn before certain services or similar). Having init scripts installed as conffiles prevents such setups from breaking after each upgrade. Regards, - -- Michael Fladischer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1aueEACgkQeJ3z1zFMUGYNkQCdE3HG5DqzHppau4cfGwtyQuL1 VZ0An1fyDawlWAzDhD8aOhqnkpgpAAkU =nlP2 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d5ab9e2.6040...@fladi.at
Re: Init scripts as conffiles
On Tue, Feb 15, 2011 at 05:27:39PM +, Tony Houghton wrote:
I'd consider packages which require editing of the init script instead
of using /etc/default or similar to be badly designed at best. I know
fixing the mass of existing packages would be too big a job, but I
thought it might be possible to provide a new option in dh_installdeb
and encourage its use for new packages.
Well, I think there are probably quite a few package maintainers who
simply don't consider that the admin might want to start a daemon in
a different way than what's provided by the initscript. For example,
the daemon in question runs as root:root and I want to wrap it to
run as a specific uid:gid pair I've created for the purpose, or the
initscript only starts one instance of a daemon and I need several
launched all pointing to individual configuration files.
I agree that pretty much all of these use cases would be valid
enough to open wishlist bugs on and include proposed patches, but a
lot of admins just want to change start behavior of a daemon (often
in complex ways not anticipated by the packager) and move on,
without having it clobbered by a stable package update later.
Obviously, when running testing/unstable/experimental or during a
dist-upgrade (and sometimes even the occasional security update),
you still have to pay attention to and manually merge changes in
your locally-modified initscripts, but the same can be said of any
conffile.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110215180545.gf1...@yuggoth.org
Re: Init scripts as conffiles
Tony Houghton h...@realh.co.uk writes: I'd consider packages which require editing of the init script instead of using /etc/default or similar to be badly designed at best. I know fixing the mass of existing packages would be too big a job, but I thought it might be possible to provide a new option in dh_installdeb and encourage its use for new packages. It's impossible to anticipate all the ways in which one may need to modify init scripts. I still have to do this routinely for Debian packages, and for reasons and in ways that I don't see how the maintainer could easily deal with via /etc/default. I think the current behavior is correct, particularly given the *substantial* simplicity gain from being able to treat everything in /etc as a conffile. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrl1w330@windlord.stanford.edu
Re: Init scripts as conffiles
Hi, Michael: On Tuesday 15 February 2011 18:37:38 Michael Fladischer wrote: Tony Houghton, 2011-02-15 17:33: I was wondering, why are init scripts installed as conffiles? Debain switched to dependency-based boot with Squeeze and those dependencies are controlled by the LSB headers inside each init script. On the majority of my systems init scripts are modified to reflect individual requirements of services during boot (e.g. openvpn before certain services or similar). Having init scripts installed as conffiles prevents such setups from breaking after each upgrade. You highlighted a very valid issue: one of the main points in going to a dependency-based init system is the ability of the sysadmin to reorganize the bootup sequence (since it's expected he knows better to workaround/reorder his local corner cases). Since dependencies are stated in the init file itself that makes it automatically a config file. Anyway, my position would be that init script shouldn't have to be config files. For this to be true these steps should need to be worked on: 1) See for boot dependencies not being stablished in the init script itself (a sourced directory under /etc/defaults?) 2) All init scripts whose related daemon accepts params on start or that define any kind of global variable (i.e.: not strictly related to Debian internals) should source an /etc/default-related file. 3) *Maybe* think about a general way for any init script to source from some file/dir if it exists. 4) Once developers are comfortable that the vast majority of init script honour these previous points, deprecate init scripts as being considered config files and file as a bug any time a sysadmin really needs to still edit one of them. Maybe steps 1,2 should be considered even if init scripts remain being considered technically config files. Cheers. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201102152033.49964.jesus.nava...@undominio.net
Re: Init scripts as conffiles
* Jesús M. Navarro jesus.nava...@undominio.net [110215 20:40]: Anyway, my position would be that init script shouldn't have to be config files. For this to be true these steps should need to be worked on: 1) See for boot dependencies not being stablished in the init script itself (a sourced directory under /etc/defaults?) 2) All init scripts whose related daemon accepts params on start or that define any kind of global variable (i.e.: not strictly related to Debian internals) should source an /etc/default-related file. 3) *Maybe* think about a general way for any init script to source from some file/dir if it exists. 4) Once developers are comfortable that the vast majority of init script honour these previous points, deprecate init scripts as being considered config files and file as a bug any time a sysadmin really needs to still edit one of them. A sysadmin never has the edit any of those files. If they need to do something special they can always change the kernel to patch the init system to change what the script can do in arbitrary ways. /sarcasm While such scripts should allow all reasonable and forseeable configuration settings be applyable outside, there are still all the unreasonable and unforseeable changes that happen every day. (execute some additional clean-up or preparational command just before, run something two times or differently, ...). If a admin is not able to do those, it's a crap system. So at least every script should be overrideable by some script the admin supplies. So what is the advantage of not having those files in /etc? (In /etc/ they should be config files (ideally conffiles). If they are not conffiles, they do not belong in /etc). The advantage of having them in /etc are: - every user understands how to change them (no need to find out where to copy a script so it overrides the distribution suplied one). - if there are changes the usual conffile handling make sure one notes if the original file changes Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110215195933.ga21...@pcpool00.mathematik.uni-freiburg.de
Re: Init scripts as conffiles
Hi On Tuesday 15 February 2011, Jesús M. Navarro wrote: Hi, Michael: On Tuesday 15 February 2011 18:37:38 Michael Fladischer wrote: Tony Houghton, 2011-02-15 17:33: I was wondering, why are init scripts installed as conffiles? Debain switched to dependency-based boot with Squeeze and those dependencies are controlled by the LSB headers inside each init script. On the majority of my systems init scripts are modified to reflect individual requirements of services during boot (e.g. openvpn before certain services or similar). Having init scripts installed as conffiles prevents such setups from breaking after each upgrade. You highlighted a very valid issue: one of the main points in going to a dependency-based init system is the ability of the sysadmin to reorganize the bootup sequence (since it's expected he knows better to workaround/reorder his local corner cases). Since dependencies are stated in the init file itself that makes it automatically a config file. You don't need (and shouldn't) edit the init script under /etc/init.d/ to adapt their boot dependencies and ~order, but rather copy just the associated LSB header to /etc/insserv/overrides/ and edit it following your needs. Anyway, my position would be that init script shouldn't have to be config files. For this to be true these steps should need to be worked on: 1) See for boot dependencies not being stablished in the init script itself (a sourced directory under /etc/defaults?) /etc/insserv/overrides/, insserv(8) 2) All init scripts whose related daemon accepts params on start or that define any kind of global variable (i.e.: not strictly related to Debian internals) should source an /etc/default-related file. 3) *Maybe* think about a general way for any init script to source from some file/dir if it exists. 4) Once developers are comfortable that the vast majority of init script honour these previous points, deprecate init scripts as being considered config files and file as a bug any time a sysadmin really needs to still edit one of them. Maybe steps 1,2 should be considered even if init scripts remain being considered technically config files. Regards Stefan Lippers-Hollmann -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201102152105.53692.s@gmx.de
Re: Init scripts as conffiles
On Tue, 15 Feb 2011, Tony Houghton wrote: I was wondering, why are init scripts installed as conffiles? Is there a good reason other than that they're in /etc and nobody bothered to make an exception in debhelper? Anything that is in /etc should be editable by the admin, and changes respected. If that's not the case, then either it's a bug that the changes aren't respected, or it's a bug that the file is in /etc in the first place. Whether this is done by making the file a conffile or otherwise handling it manually is orthogonal. See Policy §10.7 et al. Don Armstrong -- Clothes make the man. Naked people have little or no influence on society. -- Mark Twain http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110215205544.gj5...@teltox.donarmstrong.com
Re: Init scripts as conffiles
On Tue, 15 Feb 2011 16:33:25 + Tony Houghton h...@realh.co.uk wrote: I was wondering, why are init scripts installed as conffiles? Is there a good reason other than that they're in /etc and nobody bothered to make an exception in debhelper? I would have thought it would be better to treat them as not to be modified by the user/admin; any init configuration should be done via /etc/default. OK, I can see that it's probably better to leave init scripts as they are, but what I don't like about it is that init scripts get left behind when uninstalling packages. It wouldn't be quite so bad if packages called update-rc.d disable on their init scripts when removed so that init doesn't read the disused scripts, but AFAICT from the Policy Manual (sec 9.3.3.1) that isn't standard behaviour. If you try to remove them manually they don't get reinstalled if you reinstall the package later unless you use dpkg --force-conf and if you use purge you may remove other conffiles that you do want to keep. The fact that they aren't ordinary config files can cause a problem if you delete one or break it badly during editing. Ideally a program should still work and use default settings if a config file is missing, but in most cases a missing init script breaks a package quite badly. How about I file a wishlist bug for dpkg and apt for an option similar to purge but which only purges files which haven't been altered from the package's default? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110215211627.7d7eb...@realh.co.uk
Re: Init scripts as conffiles
On Tuesday 15 February 2011 15:16:27 Tony Houghton wrote: How about I file a wishlist bug for dpkg and apt for an option similar to purge but which only purges files which haven't been altered from the package's default? From what I understand, neither APT nor dpkg know if a file has been modified since it has been installed. Some packages ship with debsums, but not all. Neither the original .deb or any sort of exploded form is saved for the entire time a package is installed. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Init scripts as conffiles
Jesús M. Navarro jesus.nava...@undominio.net writes: Anyway, my position would be that init script shouldn't have to be config files. For this to be true these steps should need to be worked on: [...] Given that nearly all of the Linux distribution work on init systems right now is towards replacing the old System V init system with something like upstart or systemd, I don't think this is worth the effort. Both of those systems support far-smaller configuration files for starting daemons (and ones that should probably stay configuration files, since they avoid most of the problems of init scripts being configuration files while still providing the same features). The effort that would be put into plastering over further problems with System V init scripts could, I think, be better put into working out the details of an optional transition to a better init system. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tyg5ugdc@windlord.stanford.edu
Re: Init scripts as conffiles
On 2011-02-15 22:24 +0100, Boyd Stephen Smith Jr. wrote: On Tuesday 15 February 2011 15:16:27 Tony Houghton wrote: How about I file a wishlist bug for dpkg and apt for an option similar to purge but which only purges files which haven't been altered from the package's default? From what I understand, neither APT nor dpkg know if a file has been modified since it has been installed. Well, dpkg stores the md5sum of conffiles in its database and thus knows when they are modified, so removing unmodified conffiles would be possible in theory. However, the dpkg developers don't think this is a good idea: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351900. Sven -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrl1ufuq@turtle.gmx.de
Re: Init scripts as conffiles
On Tue, 15 Feb 2011, Tony Houghton wrote: I don't like about it is that init scripts get left behind when uninstalling packages. Configuration files are always left behind unless you purge a package. It wouldn't be quite so bad if packages called update-rc.d disable on their init scripts when removed so that init doesn't read the disused scripts, but AFAICT from the Policy Manual (sec 9.3.3.1) that isn't standard behaviour. The standard behavior is to exit 0 in the init script if the package is no longer installed; that's a fairly reasonable thing to do. The fact that they aren't ordinary config files can cause a problem if you delete one or break it badly during editing. This is the same issue that you have with /etc/default/* and many other configuration files; editing them can break the configuration and cause things not to work properly. How about I file a wishlist bug for dpkg and apt for an option similar to purge but which only purges files which haven't been altered from the package's default? I've personally never had a use case for such an option myself; either you want the package installed, you want it removed for now, but may reinstall it later, or you never want to reinstall it again. [And you were looking for --force-confmiss, btw.] Don Armstrong -- PowerPoint is symptomatic of a certain type of bureaucratic environment: one typified by interminable presentations with lots of fussy little bullet-points and flashy dissolves and soundtracks masked into the background, to try to convince the audience that the goon behind the computer has something significant to say. -- Charles Stross _The Jennifer Morgue_ p33 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110215220620.gz17...@rzlab.ucr.edu
Re: Init scripts as conffiles
On Tue, Feb 15, 2011 at 4:06 PM, Don Armstrong d...@debian.org wrote: On Tue, 15 Feb 2011, Tony Houghton wrote: I don't like about it is that init scripts get left behind when uninstalling packages. Configuration files are always left behind unless you purge a package. Sure. That doesn't make it correct, optimal, or the best option, just how things have always been done. I understand the difference between remove and purge and the reason to use both, but removing unmodified conf files seems like a win to me. Keeps the clutter down. -matt zagrabelny -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikhsv6rztzqjhvzw6qhw1jbydjntekfwlktv...@mail.gmail.com
Re: Init scripts as conffiles
On Tue, 15 Feb 2011 14:06:20 -0800 Don Armstrong d...@debian.org wrote: On Tue, 15 Feb 2011, Tony Houghton wrote: It wouldn't be quite so bad if packages called update-rc.d disable on their init scripts when removed so that init doesn't read the disused scripts, but AFAICT from the Policy Manual (sec 9.3.3.1) that isn't standard behaviour. The standard behavior is to exit 0 in the init script if the package is no longer installed; that's a fairly reasonable thing to do. Yes (not just reasonable, but quite important if redundant init scripts don't get cleaned up and you don't want error messages from them), but init has to waste time loading and interpreting the scripts. How about I file a wishlist bug for dpkg and apt for an option similar to purge but which only purges files which haven't been altered from the package's default? I've personally never had a use case for such an option myself; either you want the package installed, you want it removed for now, but may reinstall it later, or you never want to reinstall it again. [And you were looking for --force-confmiss, btw.] Well, isn't this enhanced purge ideal for the second case? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110215222919.207b4d46@toddler
Re: Init scripts as conffiles
On Tue, 15 Feb 2011 22:50:53 +0100 Sven Joachim svenj...@gmx.de wrote: On 2011-02-15 22:24 +0100, Boyd Stephen Smith Jr. wrote: On Tuesday 15 February 2011 15:16:27 Tony Houghton wrote: How about I file a wishlist bug for dpkg and apt for an option similar to purge but which only purges files which haven't been altered from the package's default? From what I understand, neither APT nor dpkg know if a file has been modified since it has been installed. Well, dpkg stores the md5sum of conffiles in its database and thus knows when they are modified, so removing unmodified conffiles would be possible in theory. However, the dpkg developers don't think this is a good idea: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351900. They didn't say they don't think it's a good idea, just that they didn't see the point, but I think a point similar to mine (that something like purge that only purges unmodified files and keeps mosified ones would be good) was in a later post that they overlooked. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110215223350.69756fdc@toddler
Re: Init scripts as conffiles
Matt Zagrabelny wrote: Sure. That doesn't make it correct, optimal, or the best option, just how things have always been done. I understand the difference between remove and purge and the reason to use both, but removing unmodified conf files seems like a win to me. Keeps the clutter down. You'll stop thinking this when apt decides to do an upgrade as follows: 1. remove foo (and its conffiles) 2. install bar 3. install foo That is one of the reasons for the current behavior, and temporarily removing a package is how apt deals with certian dependency issues. Renaming a package is another similar reason for the current behavior. -- see shy jo signature.asc Description: Digital signature
Re: Init scripts as conffiles
On Tue, Feb 15, 2011 at 4:39 PM, Joey Hess jo...@debian.org wrote: Matt Zagrabelny wrote: Sure. That doesn't make it correct, optimal, or the best option, just how things have always been done. I understand the difference between remove and purge and the reason to use both, but removing unmodified conf files seems like a win to me. Keeps the clutter down. You'll stop thinking this when apt decides to do an upgrade as follows: 1. remove foo (and its conffiles) 2. install bar 3. install foo That is one of the reasons for the current behavior, and temporarily removing a package is how apt deals with certian dependency issues. Renaming a package is another similar reason for the current behavior. 1. would remove the unmodified conf file 3. would install it Did I miss something? -matt zagrabelny -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTinkogC5+FGtJk=_Oao05S=hq3ufygn9vqauu...@mail.gmail.com
Re: Init scripts as conffiles
On Tuesday 15 February 2011 16:44:49 Matt Zagrabelny wrote: On Tue, Feb 15, 2011 at 4:39 PM, Joey Hess jo...@debian.org wrote: Matt Zagrabelny wrote: I understand the difference between remove and purge and the reason to use both, but removing unmodified conf files seems like a win to me. Keeps the clutter down. You'll stop thinking this when apt decides to do an upgrade as follows: 1. remove foo (and its conffiles) 2. install bar 3. install foo That is one of the reasons for the current behavior, and temporarily removing a package is how apt deals with certian dependency issues. Renaming a package is another similar reason for the current behavior. 1. would remove the unmodified conf file 3. would install it Did I miss something? It might be different and incompatible with the conffile(s) (if any) you did save. For example, it might no longer #include (or similar) the conffile that was saved. I would support a --purge-unchanged option, it seems like it could be useful in certain circumstances. However, something like that couldn't be the default for the same reason --purge can't be the default. I'm not sure how such a state would be representing in dpkg. uninstalled, half-configured? -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Init scripts as conffiles
On Tue, 15 Feb 2011 17:04:10 -0600 Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: On Tuesday 15 February 2011 16:44:49 Matt Zagrabelny wrote: On Tue, Feb 15, 2011 at 4:39 PM, Joey Hess jo...@debian.org wrote: Matt Zagrabelny wrote: I understand the difference between remove and purge and the reason to use both, but removing unmodified conf files seems ^^ like a win to me. Keeps the clutter down. You'll stop thinking this when apt decides to do an upgrade as follows: 1. remove foo (and its conffiles) 2. install bar 3. install foo That is one of the reasons for the current behavior, and temporarily removing a package is how apt deals with certian dependency issues. Renaming a package is another similar reason for the current behavior. 1. would remove the unmodified conf file 3. would install it Did I miss something? It might be different and incompatible with the conffile(s) (if any) you did save. For example, it might no longer #include (or similar) the conffile that was saved. I think you missed something (unmodified). I would support a --purge-unchanged option, it seems like it could be useful in certain circumstances. However, something like that couldn't be the default for the same reason --purge can't be the default. Purging only unchanged files is what we're asking for. If it's a non-default option I'd be satisfied with that. I'm not sure how such a state would be representing in dpkg. uninstalled, half-configured? Hm, good point. If it was marked not-installed would dpkg/apt still avoid clobbering a previously installed conffile? If it was marked config-files then dpkg/apt would need rewriting to make --force-confmiss the default. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110215233442.4dbd7ee4@toddler
Which files will be recorded within DEBIAN/conffiles?
I have a Debian source package. By inspecting its content, how can I tell in advance which files will be recorded within DEBIAN/conffiles? Are there documents or URLs that discuss that question? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/405478.45189...@web120711.mail.ne1.yahoo.com
Re: Which files will be recorded within DEBIAN/conffiles?
On Sun, Feb 13, 2011 at 7:41 PM, Regid Ichira regi...@yahoo.com wrote: I have a Debian source package. By inspecting its content, how can I tell in advance which files will be recorded within DEBIAN/conffiles? Are there documents or URLs that discuss that question? It depends on your package's debian/rules file. IIRC by default debhelper declares everything under /etc to be a conffile and it is possible to override that if you want to use ucf or similar. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=wkeecs2cc6rtysbum5oyhimnl0+dd1bgow...@mail.gmail.com
Re: Which files will be recorded within DEBIAN/conffiles?
Regid Ichira regi...@yahoo.com writes: I have a Debian source package. By inspecting its content, how can I tell in advance which files will be recorded within DEBIAN/conffiles? Are there documents or URLs that discuss that question? If you haven't read DebianPolicy and Debian Developer's Reference, there have something helpful. -- Regards Lei -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d57ce66.c438e70a.1f4e.4...@mx.google.com
Re: conffiles
On Tuesday 31 August 2010 05:54:26 Russ Allbery wrote: Zvi Dubitzky d...@il.ibm.com writes: Is there a way to put something in DEBIAN directory that will trigger the poped up question when overwriting config files (during package installation) before running dpkg-deb --build to generate the packge Yes, create DEBIAN/conffiles listing all the conffiles in the package. There's also a way for dpkg and friends to merge old config file with new config file without popping up questions which may be painful for your users. This is the subject of one GSoC project this year. I'll provide more details if you're interested. All the best Dominique -- http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008311739.20063.dominique.dum...@hp.com
Re: conffiles
On Tue, Aug 31, 2010 at 06:47:09AM +0300, Zvi Dubitzky wrote: Is there a way to put something in DEBIAN directory that will trigger the poped up question when overwriting config files (during package installation) before running dpkg-deb --build to generate the packge OR is there a debhelper command (dh_..) that will trigger that prior to calling dpkg-deb If you're calling dpkg-deb or adding files to the DEBIAN directory by hand, you have already failed. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100831201849.gg...@hezmatt.org
conffiles
Hi I am having conffiles file placed in debian directory and holding the configuration files ( full path) that should avoid being overwritten when installing a package , Yet when I install the built package the package config files are overwriting the existing config files at /etc without popping out a question. Is there something more needed to trigger the install time questioning ? thanks Zvi Dubitzky Email:d...@il.ibm.com -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/of5d379764.3a66b9ce-onc225778f.0067d736-c225778f.00688...@il.ibm.com
Re: conffiles
On Mon, Aug 30, 2010 at 10:01:46PM +0300, Zvi Dubitzky wrote: I am having conffiles file placed in debian directory and holding the configuration files ( full path) that should avoid being overwritten when installing a package , Yet when I install the built package the package config files are overwriting the existing config files at /etc without popping out a question. You should never need to list files in /etc as conffiles, as they're detected and a conffiles written out at package build time (because Policy says all files in /etc are conffiles). You'll almost certainly get better help if you post your source package somewhere for other people to examine, or at least provide a representative sample which demonstrates the problem you're seeing. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100830200322.gc...@hezmatt.org
Re: conffiles
Matthew Palmer mpal...@debian.org writes: On Mon, Aug 30, 2010 at 10:01:46PM +0300, Zvi Dubitzky wrote: I am having conffiles file placed in debian directory and holding the configuration files ( full path) that should avoid being overwritten when installing a package , Yet when I install the built package the package config files are overwriting the existing config files at /etc without popping out a question. You should never need to list files in /etc as conffiles, as they're detected and a conffiles written out at package build time (because Policy says all files in /etc are conffiles). This is only true if you're using debhelper, and from previous messages I believe the original poster is learning packaging by taking a more manual approach. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iq2rk5ty@windlord.stanford.edu
Re: conffiles
On Aug 30 2010, Russ Allbery wrote:
Matthew Palmer mpal...@debian.org writes:
You should never need to list files in /etc as conffiles, as they're
detected and a conffiles written out at package build time (because
Policy says all files in /etc are conffiles).
This is only true if you're using debhelper, and from previous messages I
believe the original poster is learning packaging by taking a more manual
approach.
Yes. And only if you are using some certain compatibility levels (=5).
Granted, those are likely to be used nowadays, but there are still some
packages that don't use any package helper at all (e.g., magicfilter).
Well, depending on the simpleness of the package, I usually write the
DEBIAN directory directly and the binary *is* the preferred format of
the source. :-)
Another remarkable case when this happens is when you create a
linux-image package from Linus's newer trees: nowadays, it can be a much
lighter-weight alternative to kernel-package.
Regards,
--
Rogério Brito : rbr...@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100831020427.ga12...@ime.usp.br
Re: conffiles
Hi Is there a way to put something in DEBIAN directory that will trigger the poped up question when overwriting config files (during package installation) before running dpkg-deb --build to generate the packge OR is there a debhelper command (dh_..) that will trigger that prior to calling dpkg-deb thanks Zvi Dubitzky Email:d...@il.ibm.com From: Russ Allbery r...@debian.org To: debian-mentors@lists.debian.org Date: 31/08/2010 03:03 Subject:Re: conffiles Matthew Palmer mpal...@debian.org writes: On Mon, Aug 30, 2010 at 10:01:46PM +0300, Zvi Dubitzky wrote: I am having conffiles file placed in debian directory and holding the configuration files ( full path) that should avoid being overwritten when installing a package , Yet when I install the built package the package config files are overwriting the existing config files at /etc without popping out a question. You should never need to list files in /etc as conffiles, as they're detected and a conffiles written out at package build time (because Policy says all files in /etc are conffiles). This is only true if you're using debhelper, and from previous messages I believe the original poster is learning packaging by taking a more manual approach. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iq2rk5ty@windlord.stanford.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/off1662c2f.dc3b066c-onc2257790.00142c06-c2257790.0014c...@il.ibm.com
Re: conffiles
Zvi Dubitzky d...@il.ibm.com writes: Is there a way to put something in DEBIAN directory that will trigger the poped up question when overwriting config files (during package installation) before running dpkg-deb --build to generate the packge Yes, create DEBIAN/conffiles listing all the conffiles in the package. OR is there a debhelper command (dh_..) that will trigger that prior to calling dpkg-deb dh_installdeb handles creating of conffiles if you're using debhelper (compatibility level v3 or higher). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877hj7l9n1@windlord.stanford.edu
Removing obsolete conffiles on upgrade
Hi list, as you probably all know, conffiles from older package versions are kept on package upgrades, even if the new package version does not ship the conffile anymore. How do I best get rid of such an old/obsolete conffile? Simply delete it in preinst? Do I have to check if it was modified locally and if so, do I have to keep it around/rename it? I have to get rid of the old conffile somehow (I formerly had two files foo and bar. In the new package version, the content of foo has been included in bar, so I want to get rid of foo, otherwise I get clashes). Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Removing obsolete conffiles on upgrade
On Fre, 09 Feb 2007, Michael Biebl wrote: I have to get rid of the old conffile somehow (I formerly had two files foo and bar. In the new package version, the content of foo has been included in bar, so I want to get rid of foo, otherwise I get clashes). Well the optimum solution is the following (all in preinst): - If foo was unchanged from the original version (check md5sum) then just remove it - otherwise *try* to merge the changes in foo into bar. - if this is not possible, warn the admin that he has to manually update the settings in bar according to what he has done in foo. Best wishes Norbert --- Dr. Norbert Preining [EMAIL PROTECTED]Università di Siena Debian Developer [EMAIL PROTECTED] Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- `What's been happening here?' he demanded. `Oh just the nicest things, sir, just the nicest things. can I sit on your lap please?' `Colin, I am going to abandon you to your fate.' `I'm so happy.' `It will be very, very nasty for you, and that's just too bad. Got it?' `I gurgle with pleasure.' --- Ford and Colin the robot. --- Douglas Adams, The Hitchhikers Guide to the Galaxy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed conffiles?
Manoj Srivastava [EMAIL PROTECTED] writes: This is the beauty of free software. If you find it so frustrating, write up a generic tool, and contribute it. And that would follow the grand old UNIX tradition of each command doing one thing well. I may be of some help here. I've written a tool that enable you to extract the information from configuration files, check the data and write it back. Of course, there's no miracle. For this tool to work, you must provide details on its structure (i.e. a model), how to read data (parser, which can also take care of upgrade problems), and how to write data back. Declaring a configuration model (instead of hard coding the behavior) greatly helps maintenance. The tool I've written also provides generic user interfaces. If you're interested in this tool, we can further discuss it in a new thread (may be in another list). Cheers -- Dominique Dumont Delivering successful solutions requires giving people what they need, not what they want. Kurt Bittner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed conffiles?
On Sat, Jan 20, 2007 at 01:14:59PM -0600, Manoj Srivastava wrote: On Sat, 20 Jan 2007 18:46:20 +0100, Marc Haber [EMAIL PROTECTED] said: On Sat, Jan 20, 2007 at 11:38:39AM -0600, Manoj Srivastava wrote: On Sat, 20 Jan 2007 18:17:27 +0100, Marc Haber [EMAIL PROTECTED] said: There is no need to fork ucf to create a command that provides functionality not in ucf. the intersection between zmct (zugschlus' magical conffiles tool) and ucf would be non-negligible and a lot of routine stuff would need to be present in both packages. err, why would there be anything non-negligible beyond a single grep call in common? I fail to see why there will be mounds and mounds of common stuff -- as the tetex example already demonstrates. I haven't thought about this in the necessary depth. To a newbie DD who has only been with Debian for six years it looks like ucf is not completely finished. And, arguably, this functionality should be in a different script anyway, perhaps one that can read the simple ucf cache, which, given the installed base, is unlikely to change from under you. Where is the documentation of the stable interface to ucf's cache that is reliable not to change between ucf releases? My goodness. Are we so lost in ISO 9000 processes that we need formal documentation to realize that ucf hash files have a md5sum and a file path? And to realize that the hashfile exists on user machines, and changing formats will be a major effort now? ucf could suddenly start to write the hashfile in some other format while still being able to read the old format. If a change like this is not coordinated between the hypothetical zmct and ucf, all packages using zmct will suddenly be RC-buggy. And I remember you scolding me for using an internal kernel-package interface back in 2001. This has nothing to do with ISO900x (which I hate with a passion). It is about stability. Then it is good for you tat the tetex folks hve written the (simple) wrapper code for you -- and the complex common part was: md5sum=$(grep $file$ /var/lib/ucf/hashfile | cut -f 1 -d ' ') I suspect that there is some wrapper code needed anyway which is the actual hard part (taking care of special cases). Additionally, imagine this code being scattered away to 100 packages and then some obscure bug surfacing. Currently, ucf does a lot less than dpkg does. What ucf does, it does much better than dpkg. But since there are still things that dpkg handles quite well while ucf basically says well, code it yourself, ucf does not provider conffile like handling as it is advertising in its package description. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed conffiles?
On Wed, 24 Jan 2007 12:52:53 +0100, Marc Haber [EMAIL PROTECTED] said: I haven't thought about this in the necessary depth. To a newbie DD who has only been with Debian for six years it looks like ucf is not completely finished. ucf scratches the itch I had to begin with, and it does everything my packages need it to do. Feature creep is to be guarded against. I suspect that there is some wrapper code needed anyway which is the actual hard part (taking care of special cases). Additionally, imagine this code being scattered away to 100 packages and then some obscure bug surfacing. I suspect that generalizing the specific code might make it harder. For example, the previous md5sum specification is unnecesarily complex in a generic tool; and much easier in the maintainer scripts where each maintainer can choose the best method that works for them Currently, ucf does a lot less than dpkg does. Well, duh. What ucf does, it does much better than dpkg. Why, thank you. But since there are still things that dpkg handles quite well while ucf basically says well, code it yourself, ucf does not provider conffile like handling as it is advertising in its package description. Matter of opinion. ucf's man page says: preserve user changes in configuration files. ucf is a prompting tool -- and is designed to handle user interaction, and copy files in place if the user says so. That's all it does. ucf. Actually, the challenge is there _BECAUSE_ ucf was not designed to address this issue (which it actually should) and its maintainer considers this missing feature a feature. Why should ucf provide a means for removing old configuration files as well? It is not code that is in common with the current functionality. Hell, you don't even need ucf. You look to see if the current files md5sum matches any known md5sums, and you knwo if it is an unmodified file. I still feel that the right place to do this is the tool that claims to be able to replace dpkg conffile (sic!) handling, ucf. Why should ucf be involved at all? This is not what ucf does. manoj -- This is NOT a repeat. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed conffiles?
On Fri, 19 Jan 2007, Justin Pryzby wrote: You will have to test with both sarge and etch dpkg (until after etch releases). Colin Watson recently wrote [0] about one of the ssh bugs and how this was complicated for him. You have to include the logic in the preinst, since the prerm is for the old package, since the postinst happens after the conffile prompts, and since the postrm happens post rm... For sarge dpkg, your logic is correct. AFAIU in Colin's case (perhaps only because of the Replaces) the logic causes at least as many problems as it solves, since etch dpkg specifically and deliberately prompts the user about conffile's which were deleted (sarge dpkg assumes that such deletion was intentional). No dpkg prompts here. It's a self-managed configuration file, i.e. it's not a conffile, as such term is reserved for a conffile in the dpkg sense. Yes, the subject is misleading. Please, people, don't use the word conffile to refer to configuration files which are not conffiles. Thanks :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed conffiles?
On Fri, Jan 19, 2007 at 09:43:04PM +0100, Santiago Vila wrote: On Fri, 19 Jan 2007, Marc Haber wrote: I have a package with a bunch of configuration files that are managed by my maintainer scripts and not by dpkg. I now need one of them (a.conf) to vanish. How do I do this in a clean way? I am thinking about the following: (1) Let the new package version know about the md5sum of the last version(s) of a.conf that were in the package. (2) If one of the md5sums matches, the file has not been changed, remove it. (3) If none of the md5sums matches, the file has locally been changed, rename it to a.conf.package-old Instead of 1,2,3 you could do 1,2,3 only when upgrading from a version previous than the one not having a.conf anymore, and in case that (3) happens, keep a.conf untouched, instead of renaming it (assuming the program will not read a.conf anymore). Yes, that sounds sensible. It is, however, frustrating that there is no method (for example, offered by ucf) to do this without that much coding in maintainer scripts. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed conffiles?
On Fri, Jan 19, 2007 at 10:28:41PM -0500, Justin Pryzby wrote: You will have to test with both sarge and etch dpkg (until after etch releases). Colin Watson recently wrote [0] about one of the ssh bugs and how this was complicated for him. You have to include the logic in the preinst, since the prerm is for the old package, since the postinst happens after the conffile prompts, and since the postrm happens post rm... This sounds like a horrible mess and a gazillion ways to do things wrong. Is there a reference package that does things completely right? Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed conffiles?
On Sat, 20 Jan 2007 10:47:16 +0100, Marc Haber [EMAIL PROTECTED] said: Yes, that sounds sensible. It is, however, frustrating that there is no method (for example, offered by ucf) to do this without that much coding in maintainer scripts. This is the beauty of fre software. If you find it so frustrating, write up a generic tool, and contribute it. And that would follow the grand old UNIX tradition of each command doing one thing well. manoj -- Flattery is all right -- if you don't inhale. Adlai Stevenson Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed conffiles?
On Sat, Jan 20, 2007 at 10:31:11AM -0600, Manoj Srivastava wrote: This is the beauty of fre software. If you find it so frustrating, write up a generic tool, and contribute it. And that would follow the grand old UNIX tradition of each command doing one thing well. The task at hand would mean forking ucf, which would be a bad idea. Additionally, I'd like a functionality of this importance in a better coder's hand than mine. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed conffiles?
On Sat, 20 Jan 2007 18:17:27 +0100, Marc Haber [EMAIL PROTECTED] said: On Sat, Jan 20, 2007 at 10:31:11AM -0600, Manoj Srivastava wrote: This is the beauty of fre software. If you find it so frustrating, write up a generic tool, and contribute it. And that would follow the grand old UNIX tradition of each command doing one thing well. The task at hand would mean forking ucf, which would be a bad idea. Then I am sorry to say you have not learned how free software works. There is no need to fork ucf to create a command that provides functionality not in ucf. And, arguably, this functionality should be in a different script anyway, perhaps one that can read the simple ucf cache, which, given the installed base, is unlikely to change from under you. Additionally, I'd like a functionality of this importance in a better coder's hand than mine. Write the code. You might surprise yourself. Or find that other people can help out. Or you could contribute the code to be included in ucf. But the first step is do the work. manoj -- I hate babies. They're so human. H.H. Munro Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed conffiles?
On Sat, Jan 20, 2007 at 11:38:39AM -0600, Manoj Srivastava wrote: On Sat, 20 Jan 2007 18:17:27 +0100, Marc Haber [EMAIL PROTECTED] said: On Sat, Jan 20, 2007 at 10:31:11AM -0600, Manoj Srivastava wrote: This is the beauty of fre software. If you find it so frustrating, write up a generic tool, and contribute it. And that would follow the grand old UNIX tradition of each command doing one thing well. The task at hand would mean forking ucf, which would be a bad idea. Then I am sorry to say you have not learned how free software works. Your opinion. Agree to disagree? There is no need to fork ucf to create a command that provides functionality not in ucf. the intersection between zmct (zugschlus' magical conffiles tool) and ucf would be non-negligible and a lot of routine stuff would need to be present in both packages. And, arguably, this functionality should be in a different script anyway, perhaps one that can read the simple ucf cache, which, given the installed base, is unlikely to change from under you. Where is the documentation of the stable interface to ucf's cache that is reliable not to change between ucf releases? Additionally, I'd like a functionality of this importance in a better coder's hand than mine. Write the code. You might surprise yourself. Or find that other people can help out. Or you could contribute the code to be included in ucf. But the first step is do the work. insufficient time resources. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed conffiles?
On Sat, 20 Jan 2007 18:46:20 +0100, Marc Haber [EMAIL PROTECTED] said: On Sat, Jan 20, 2007 at 11:38:39AM -0600, Manoj Srivastava wrote: On Sat, 20 Jan 2007 18:17:27 +0100, Marc Haber [EMAIL PROTECTED] said: There is no need to fork ucf to create a command that provides functionality not in ucf. the intersection between zmct (zugschlus' magical conffiles tool) and ucf would be non-negligible and a lot of routine stuff would need to be present in both packages. err, why would there be anything non-negligible beyond a single grep call in common? I fail to see why there will be mounds and mounds of common stuff -- as the tetex example already demonstrates. And, arguably, this functionality should be in a different script anyway, perhaps one that can read the simple ucf cache, which, given the installed base, is unlikely to change from under you. Where is the documentation of the stable interface to ucf's cache that is reliable not to change between ucf releases? My goodness. Are we so lost in ISO 9000 processes that we need formal documentation to realize that ucf hash files have a md5sum and a file path? And to realize that the hashfile exists on user machines, and changing formats will be a major effort now? Additionally, I'd like a functionality of this importance in a better coder's hand than mine. Write the code. You might surprise yourself. Or find that other people can help out. Or you could contribute the code to be included in ucf. But the first step is do the work. insufficient time resources. Then it is good for you tat the tetex folks hve written the (simple) wrapper code for you -- and the complex common part was: md5sum=$(grep $file$ /var/lib/ucf/hashfile | cut -f 1 -d ' ') manoj -- Darth Vader sleeps with a Teddywookie. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Removing self-managed conffiles?
Hi, I have a package with a bunch of configuration files that are managed by my maintainer scripts and not by dpkg. I now need one of them (a.conf) to vanish. How do I do this in a clean way? I am thinking about the following: (1) Let the new package version know about the md5sum of the last version(s) of a.conf that were in the package. (2) If one of the md5sums matches, the file has not been changed, remove it. (3) If none of the md5sums matches, the file has locally been changed, rename it to a.conf.package-old Is that acceptable? Or is there anything easier, more elegant, more policy compliant? Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed conffiles?
On Fri, 19 Jan 2007, Marc Haber wrote: Hi, I have a package with a bunch of configuration files that are managed by my maintainer scripts and not by dpkg. I now need one of them (a.conf) to vanish. How do I do this in a clean way? I am thinking about the following: (1) Let the new package version know about the md5sum of the last version(s) of a.conf that were in the package. (2) If one of the md5sums matches, the file has not been changed, remove it. (3) If none of the md5sums matches, the file has locally been changed, rename it to a.conf.package-old Instead of 1,2,3 you could do 1,2,3 only when upgrading from a version previous than the one not having a.conf anymore, and in case that (3) happens, keep a.conf untouched, instead of renaming it (assuming the program will not read a.conf anymore). Is that acceptable? Or is there anything easier, more elegant, more policy compliant? Other than that it seems completely acceptable to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed conffiles?
Santiago Vila [EMAIL PROTECTED] wrote: Instead of 1,2,3 you could do 1,2,3 only when upgrading from a version previous than the one not having a.conf anymore Sure. and in case that (3) happens, keep a.conf untouched, instead of renaming it (assuming the program will not read a.conf anymore). Hmm, I don't like this much, because it contributes to /etc pollution. There are so many things in that directory that it's often difficult to know when you can safely remove something that looks like cruft (especially after dpkg's messages Non-empty directory 'foo' coudn't be removed or so). So, IMHO, it's much better when the maintainer scripts of the Package Who Knows tell you that $file can be safely removed (and even better, give it a name ending in .package-old, as Marc suggested). -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed conffiles?
On Fri, Jan 19, 2007 at 09:34:28AM +0100, Marc Haber wrote: Hi, I have a package with a bunch of configuration files that are managed by my maintainer scripts and not by dpkg. I now need one of them (a.conf) to vanish. How do I do this in a clean way? I am thinking about the following: (1) Let the new package version know about the md5sum of the last version(s) of a.conf that were in the package. (2) If one of the md5sums matches, the file has not been changed, remove it. (3) If none of the md5sums matches, the file has locally been changed, rename it to a.conf.package-old You will have to test with both sarge and etch dpkg (until after etch releases). Colin Watson recently wrote [0] about one of the ssh bugs and how this was complicated for him. You have to include the logic in the preinst, since the prerm is for the old package, since the postinst happens after the conffile prompts, and since the postrm happens post rm... For sarge dpkg, your logic is correct. AFAIU in Colin's case (perhaps only because of the Replaces) the logic causes at least as many problems as it solves, since etch dpkg specifically and deliberately prompts the user about conffile's which were deleted (sarge dpkg assumes that such deletion was intentional). Justin References [0] http://lists.debian.org/debian-release/2006/12/msg01105.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
detecting cutomized conffiles and debconf
Hello Mentors, to make the long story short this is an how to deal existing conffiles and a new set of debconf questions to setup the package? question. Now, the package is cpufrequtils and what I'd like to achieve is providing some nice debconf templates to configure /etc/default/cpufrequtils which will allow the user to set a boottime policy. At the same time I'd like to avoid annoying users who already customized their configuration (I assume they don't need to be questioned again) and obviously avoid overwriting their customized file. Which is the way to go? AFAICT debsums could help or maybe should I not make /etc/default/cpufrequtils a conffile and manually manage it? Thanks in advance -- mattia :wq! signature.asc Description: Digital signature
Re: detecting cutomized conffiles and debconf
Hi Mattia, Op ma, 11-09-2006 te 21:01 +0200, schreef Mattia Dongili: Hello Mentors, to make the long story short this is an how to deal existing conffiles and a new set of debconf questions to setup the package? question. Now, the package is cpufrequtils and what I'd like to achieve is providing some nice debconf templates to configure /etc/default/cpufrequtils which will allow the user to set a boottime policy. At the same time I'd like to avoid annoying users who already customized their configuration (I assume they don't need to be questioned again) and obviously avoid overwriting their customized file. Which is the way to go? AFAICT debsums could help or maybe should I not make /etc/default/cpufrequtils a conffile and manually manage it? If you change the contents of a configuration file in your maintainer scripts, for instance by using debconf, they should not be conffiles but regular configuration files. See Debian policy on this. You should stop shipping the file as conffile, read in the configfile in your preinst, save the values for use with debconf, and then make the file a configuration file. Greetings Arjan signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: Symlinks as conffiles?
On Thu, Jun 29, 2006 at 09:24:03PM -0500, TNKS wrote: Hi, I hope this is not off-topic for this forum. I have a simple question, and there's _so_ many forums it's tough to find the best one. I'm a long-time user of Debian trying to learn more about the distribution and also the Policy. Someone on #debian mentioned that symlinks can be included in the package file listing. If that's the case, can symlinks also be conffiles? Will dpkg make .dpkg-old symlinks and the like if the user changes the target of the symlink? Yes Even if it works, is it not recommended because of some corner-case(s) dpkg just isn't designed for? Correct, even if the recommendation is just mine.. See the lessdisks-terminal bug #360673 and its clone for why this [can] be really bad. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Symlinks as conffiles?
Hi, I hope this is not off-topic for this forum. I have a simple question, and there's _so_ many forums it's tough to find the best one. I'm a long-time user of Debian trying to learn more about the distribution and also the Policy. Someone on #debian mentioned that symlinks can be included in the package file listing. If that's the case, can symlinks also be conffiles? Will dpkg make .dpkg-old symlinks and the like if the user changes the target of the symlink? Even if it works, is it not recommended because of some corner-case(s) dpkg just isn't designed for? I'm using GMane to post to this forum as a newgroup. I'll just check back here periodically, so feel free to just post back to the forum and not worry about cc'ing me. Thanks for your feedback, Sukant Hajra -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing former conffiles
Don Armstrong [EMAIL PROTECTED] wrote: People who forgot (or never noticed) that the file is generated from files in conf.d will open /etc/texmf/bla.conf in their favorite editor, change the generated file without noticing, and will be surprised if the change is lost after the next package upgrade. This should be an indication that you're not preserving administrator changes to configuration files if this occurs... Err, no. If the conffiles are in /etc/bla.d/, the generated file bla.conf is in /var/lib/bla/, and there's a symlink chain from /usr/share/bla/bla.conf to /etc/bla.conf and on to /var/lib/bla/bla.conf, then there are two things I need to preserve: One is the state of /etc/bla.conf (is it a symlink or a real file?) and the other is the conffiles in /etc/bla.d/. Of course there would be a remark at the top of /var/lib/bla/bla.conf as to not edit it, but we all know that users don't necessarily read that. This is why I think the symlink from /etc to /var idea isn't good. Either the program is able to read from conf.d, or there is a generated file that is accessed by the program without an additional indirection via /etc. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Removing former conffiles
Don Armstrong [EMAIL PROTECTED] wrote: On Tue, 07 Feb 2006, Frank Küster wrote: Don Armstrong [EMAIL PROTECTED] wrote: On Tue, 07 Feb 2006, Frank Küster wrote: Don Armstrong [EMAIL PROTECTED] wrote: Right. The problem is that it's not always easy to know if the file will no longer be read at all; you can't assume that the administrator has left in place your default configuration system. Of course the maintainer should know their package. If the binary reads a configuration file in /usr/share/bla, and in the old version there was This would be a problem. Why? What problem? You've now got a conffile in a location which is not /etc, namely /var/lib/bla, which cannot be overridden by the administrator. No, I don't. The program reads its configuration from a file in /var/lib/bla, but the conffiles (or configuration files) reside in /etc/bla/bla.d. Instead, I'd suggest having the symlink in /usr/share/bla pointing to /etc/bla.cnf which then in the default install is a symlink to /var/lib/bla or whatever is appropriate; if the user has modified the configuration file, you don't stick in the symlink. That's a possible approach; however teTeX is different. There's an other method to override the Debian integration. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Removing former conffiles
On Wed, 08 Feb 2006, Frank Küster wrote: Don Armstrong [EMAIL PROTECTED] wrote: You've now got a conffile in a location which is not /etc, namely /var/lib/bla, which cannot be overridden by the administrator. No, I don't. The program reads its configuration from a file in /var/lib/bla, but the conffiles (or configuration files) reside in /etc/bla/bla.d. The configuration file is the file from which the configuration is read, that is, the file in /var/lib/blah which isn't in /etc. This setup forces the administrator to use a your special conffile setup which they can't override.[1] The double symlink method enables them to both: 1) Override your method 2) Use your method exactly as they would without the double symlink In addition, you get compliance with policy, and an implementation which is more obvious to the administrator. A third option would be to build the conffile in /var/lib/blah, and use ucf or similar to prompt for the difference betwen /var/lib/blah and /etc/blah. Don Armstrong 1: In the sense that they can't decide that using the conf.d is silly and ship a single configuration file. -- When I was a kid I used to pray every night for a new bicycle. Then I realised that the Lord doesn't work that way so I stole one and asked Him to forgive me. -- Emo Philips. http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Removing former conffiles
Don Armstrong [EMAIL PROTECTED] wrote: On Wed, 08 Feb 2006, Frank Küster wrote: Don Armstrong [EMAIL PROTECTED] wrote: You've now got a conffile in a location which is not /etc, namely /var/lib/bla, which cannot be overridden by the administrator. No, I don't. The program reads its configuration from a file in /var/lib/bla, but the conffiles (or configuration files) reside in /etc/bla/bla.d. The configuration file is the file from which the configuration is read, that is, the file in /var/lib/blah which isn't in /etc. Why? This setup forces the administrator to use a your special conffile setup which they can't override.[1] [...] 1: In the sense that they can't decide that using the conf.d is silly and ship a single configuration file. Okay, I see your point. Generally I agree with you, although in the particular example, teTeX, your're wrong: They still can override the scheme. In addition, you get compliance with policy, Our setup is also policy-compliant. and an implementation which is more obvious to the administrator. And clutters /etc/texmf unnecessarily. And has one more severe drawback: People who forgot (or never noticed) that the file is generated from files in conf.d will open /etc/texmf/bla.conf in their favorite editor, change the generated file without noticing, and will be surprised if the change is lost after the next package upgrade. A third option would be to build the conffile in /var/lib/blah, and use ucf or similar to prompt for the difference betwen /var/lib/blah and /etc/blah. Been there, done something similar. ucf is a nice workaround for a missing feature in dpkg, but it confuses users. I avoid it if I can. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Removing former conffiles
On Wed, 08 Feb 2006, Frank Küster wrote: Don Armstrong [EMAIL PROTECTED] wrote: The configuration file is the file from which the configuration is read, that is, the file in /var/lib/blah which isn't in /etc. [...] 1: In the sense that they can't decide that using the conf.d is silly and ship a single configuration file. Okay, I see your point. Generally I agree with you, although in the particular example, teTeX, your're wrong: They still can override the scheme. Heh. There's a reason why we're talking about package 'blah' here. ;-) People who forgot (or never noticed) that the file is generated from files in conf.d will open /etc/texmf/bla.conf in their favorite editor, change the generated file without noticing, and will be surprised if the change is lost after the next package upgrade. This should be an indication that you're not preserving administrator changes to configuration files if this occurs... A third option would be to build the conffile in /var/lib/blah, and use ucf or similar to prompt for the difference betwen /var/lib/blah and /etc/blah. Been there, done something similar. ucf is a nice workaround for a missing feature in dpkg, but it confuses users. I avoid it if I can. I actually like ucf, but the point here is that it's another option which is also policy compliant. Don Armstrong -- Dropping non-free would set us back at least, what, 300 packages? It'd take MONTHS to make up the difference, and meanwhile Debian users will be fleeing to SLACKWARE. And what about SHAREHOLDER VALUE? -- Matt Zimmerman in [EMAIL PROTECTED] http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Removing former conffiles
Justin Pryzby [EMAIL PROTECTED] wrote: On Mon, Feb 06, 2006 at 10:02:06PM +0100, Frank K?ster wrote: Bas Wijnen [EMAIL PROTECTED] wrote: The question is, how do I solve this? Should I forcefully remove the conffile before calling update-rc.d? It feels really bad to remove files from /etc in maintainer scripts, but perhaps it's the right thing to do... - if the file is unchanged, remove it Even changed files are removed on purge. Yes, of course - I should have been more clear. What I wrote is done in preinst. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Removing former conffiles
Don Armstrong [EMAIL PROTECTED] wrote: On Mon, 06 Feb 2006, Frank Küster wrote: - if it is changed, either keep it and insert a comment at its beginning that it is unused, or move/rename it. In all cases where the file's presence could have a bad effect, I renamed or moved it. Just a word of caution here: If the administrator has modified the file, you should not rename or move it, as they may know better than you what they're doing. A proper course of action would be warning them, and/or offering to remove the files in question via debconf. If I know that the file will no longer be read at all, there's no point in pretending that it still have an effect. Renaming it makes this completely clear. If it's just a the file is no longer needed, then of course I need not do anything, but a warning, debconf question, or just an entry in NEWS.Debian would be good. There's yet an other case: If the postinst script finds that a conf(iguration) file has a setting that will break later postinst action, and result in an unconfigured package, then it should fail right away and give an explanation (and not try to proceed and fail later with a much less understandable error message). Additionally, you should check to make sure whether you're upgrading from a version after this transition; if that's the case, you shouldn't rename/delete either. Yes, that should always be done. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Removing former conffiles
On Tue, 07 Feb 2006, Frank Küster wrote: Don Armstrong [EMAIL PROTECTED] wrote: Just a word of caution here: If the administrator has modified the file, you should not rename or move it, as they may know better than you what they're doing. A proper course of action would be warning them, and/or offering to remove the files in question via debconf. If I know that the file will no longer be read at all, there's no point in pretending that it still have an effect. Renaming it makes this completely clear. Right. The problem is that it's not always easy to know if the file will no longer be read at all; you can't assume that the administrator has left in place your default configuration system. [Likewise for failure modes on the presence of an obsolete configuration file; unless you know for certain that it will fail, you should give the administrator some way to override your guess.] Don Armstrong -- A people living under the perpetual menace of war and invasion is very easy to govern. It demands no social reforms. It does not haggle over expenditures on armaments and military equipment. It pays without discussion, it ruins itself, and that is an excellent thing for the syndicates of financiers and manufacturers for whom patriotic terrors are an abundant source of gain. -- Anatole France http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Removing former conffiles
Don Armstrong [EMAIL PROTECTED] wrote: Right. The problem is that it's not always easy to know if the file will no longer be read at all; you can't assume that the administrator has left in place your default configuration system. Of course the maintainer should know their package. If the binary reads a configuration file in /usr/share/bla, and in the old version there was a symlink from /usr/share/bla/bla.conf to /etc/bla/bla.conf, but now the file is generated from files in /etc/bla/conf.d, sits in /var/lib/bla, and the symlink points there, it's safe to assume that /etc/bla/bla.conf is unused. [Likewise for failure modes on the presence of an obsolete configuration file; unless you know for certain that it will fail, you should give the administrator some way to override your guess.] In some cases, yes. We have cases in teTeX where there are only two alternatives: Either accept the change, or not install the debianized package at all and go for /usr/local/ instead. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Removing former conffiles
On Tue, 07 Feb 2006, Frank Küster wrote: Don Armstrong [EMAIL PROTECTED] wrote: Right. The problem is that it's not always easy to know if the file will no longer be read at all; you can't assume that the administrator has left in place your default configuration system. Of course the maintainer should know their package. If the binary reads a configuration file in /usr/share/bla, and in the old version there was This would be a problem. a symlink from /usr/share/bla/bla.conf to /etc/bla/bla.conf, but now the file is generated from files in /etc/bla/conf.d, sits in /var/lib/bla, and the symlink points there, it's safe to assume that /etc/bla/bla.conf is unused. The issue here is that you've suddenly changed the way the system works, so perhaps the proper method is to move /etc/blah/bla.conf into /etc/bla/conf.d/ instead; at the very least you should move the users configuration away into a backup position or something rather than deleting it if they have made changes. In some cases, yes. We have cases in teTeX where there are only two alternatives: Either accept the change, or not install the debianized package at all and go for /usr/local/ instead. That seems like a bug to me; it may not be easy to fix in tetex, but it's definetly not the ideal situtation for a package. Don Armstrong -- The question of whether computers can think is like the question of whether submarines can swim. -- Edsgar Dijkstra http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Removing former conffiles
Don Armstrong [EMAIL PROTECTED] wrote: On Tue, 07 Feb 2006, Frank Küster wrote: Don Armstrong [EMAIL PROTECTED] wrote: Right. The problem is that it's not always easy to know if the file will no longer be read at all; you can't assume that the administrator has left in place your default configuration system. Of course the maintainer should know their package. If the binary reads a configuration file in /usr/share/bla, and in the old version there was This would be a problem. Why? What problem? a symlink from /usr/share/bla/bla.conf to /etc/bla/bla.conf, but now the file is generated from files in /etc/bla/conf.d, sits in /var/lib/bla, and the symlink points there, it's safe to assume that /etc/bla/bla.conf is unused. The issue here is that you've suddenly changed the way the system works, so perhaps the proper method is to move /etc/blah/bla.conf into /etc/bla/conf.d/ instead; at the very least you should move the users configuration away into a backup position or something rather than deleting it if they have made changes. I never talked about deleting it. In some cases we indeed managed to transfer it. There might be others where it isn't possible. It might also be that the binary simply stops looking for that particular conffile because the configuration options are obsolete. In some cases, yes. We have cases in teTeX where there are only two alternatives: Either accept the change, or not install the debianized package at all and go for /usr/local/ instead. That seems like a bug to me; it may not be easy to fix in tetex, but it's definetly not the ideal situtation for a package. Go ahead and submit bugs, and we'll discuss whether there's a better solution. One example: TeX input files are found in any path (TEXMF tree) defined in the TEXMF variable. We had to move teTeX's files from /usr/share/texmf (which continues to be a TEXMF tree for other packages) into /usr/share/texmf-tetex, and consequently we need to add this new tree into the list in the variable TEXMF. If the user refuses this change upon upgrade, what other choice do we have? We check for it in postinst and bail out before trying to do any configure work which will fail for sure. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Removing former conffiles
On Tue, Feb 07, 2006 at 11:35:01AM -0800, Don Armstrong wrote: On Tue, 07 Feb 2006, Frank K?ster wrote: Don Armstrong [EMAIL PROTECTED] wrote: Right. The problem is that it's not always easy to know if the file will no longer be read at all; you can't assume that the administrator has left in place your default configuration system. Of course the maintainer should know their package. If the binary reads a configuration file in /usr/share/bla, and in the old version there was This would be a problem. Not really, just nonideal; policy even covers it: |10.7.2 Location | |Any configuration files created or used by your package must reside in |/etc. If there are several, consider creating a subdirectory of /etc |named after your package. | |If your package creates or uses configuration files outside of /etc, |and it is not feasible to modify the package to use /etc directly, put |the files in /etc and create symbolic links to those files from the |location that the package requires. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing former conffiles
On Tue, 07 Feb 2006, Frank Küster wrote: Don Armstrong [EMAIL PROTECTED] wrote: On Tue, 07 Feb 2006, Frank Küster wrote: Don Armstrong [EMAIL PROTECTED] wrote: Right. The problem is that it's not always easy to know if the file will no longer be read at all; you can't assume that the administrator has left in place your default configuration system. Of course the maintainer should know their package. If the binary reads a configuration file in /usr/share/bla, and in the old version there was This would be a problem. Why? What problem? You've now got a conffile in a location which is not /etc, namely /var/lib/bla, which cannot be overridden by the administrator. Instead, I'd suggest having the symlink in /usr/share/bla pointing to /etc/bla.cnf which then in the default install is a symlink to /var/lib/bla or whatever is appropriate; if the user has modified the configuration file, you don't stick in the symlink. If the user hasn't, you put in the symlink. [Of course, ideally you'd have a configuration file language that would enable you to just include the conf.d directly... but that may not always be possible.] Don Armstrong -- The trouble with you, Ibid he said, is that you think you're the biggest bloody authority on everything -- Terry Pratchet _Pyramids_ p146 http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Removing former conffiles
On Tue, Feb 07, 2006 at 12:28:39AM -0800, Don Armstrong wrote: On Tue, 07 Feb 2006, Frank K?ster wrote: Don Armstrong [EMAIL PROTECTED] wrote: Just a word of caution here: If the administrator has modified the file, you should not rename or move it, as they may know better than you what they're doing. A proper course of action would be warning them, and/or offering to remove the files in question via debconf. If I know that the file will no longer be read at all, there's no point in pretending that it still have an effect. Renaming it makes this completely clear. Right. The problem is that it's not always easy to know if the file will no longer be read at all; you can't assume that the administrator has left in place your default configuration system. [Likewise for failure modes on the presence of an obsolete configuration file; unless you know for certain that it will fail, you should give the administrator some way to override your guess.] The package is a dummy transition package. When this version of gnocatan is installed, no gnocatan config files will be read at all anymore. It might have been a good idea to try and convert it into a pioneers config file (the new name of the package), but as long as the name includes gnocatan, it's not going to have any effect, since there are no binaries in the gnocatan-* packages anymore (well, except this maintainer script). Would that mean it's ok to remove it? Or should I better rename it so they can use it to convert to a pioneers file by hand? Perhaps that's the best... I could make a NEWS message about that as well. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: Removing former conffiles
On Tue, Feb 07, 2006 at 11:47:49PM +0100, Bas Wijnen wrote: On Tue, Feb 07, 2006 at 12:28:39AM -0800, Don Armstrong wrote: On Tue, 07 Feb 2006, Frank K?ster wrote: Don Armstrong [EMAIL PROTECTED] wrote: Just a word of caution here: If the administrator has modified the file, you should not rename or move it, as they may know better than you what they're doing. A proper course of action would be warning them, and/or offering to remove the files in question via debconf. If I know that the file will no longer be read at all, there's no point in pretending that it still have an effect. Renaming it makes this completely clear. Right. The problem is that it's not always easy to know if the file will no longer be read at all; you can't assume that the administrator has left in place your default configuration system. [Likewise for failure modes on the presence of an obsolete configuration file; unless you know for certain that it will fail, you should give the administrator some way to override your guess.] The package is a dummy transition package. When this version of gnocatan is installed, no gnocatan config files will be read at all anymore. It might have been a good idea to try and convert it into a pioneers config file (the new name of the package), but as long as the name includes gnocatan, it's not going to have any effect, since there are no binaries in the gnocatan-* packages anymore (well, except this maintainer script). Would that mean it's ok to remove it? Or should I better rename it so they can use it to convert to a pioneers file by hand? Perhaps that's the best... I could make a NEWS message about that as well. I think the right thing to do here is to simply remove it if we can determine that it's unmodified. Well, really, I think the right thing is for *dpkg* to remove it if it can determine that it's unmodified; this is bug #330256. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Removing former conffiles
Hello, After bug report #339387, I added a postinst file to the dummy package gnocatan-meta-server, which does update-rc.d gnocatan-meta-server remove /dev/null || true in order to get rid of the links which were created by the previous (non-dummy) version of the package. However, this didn't seem to work. Appearantly this is what happened: - The non-dummy package created the conffile - The package was upgraded to the dummy version, which no longer held the conffile. However, it being a conffile, it was not removed (perhaps this is only true if it was actually changed?) - On purging the dummy package, the conffile is not removed because it isn't listed as part of the package. - update-rc.d then refuses to remove the links, because the file is still there. - Both the conffile and the links remain on the system. The question is, how do I solve this? Should I forcefully remove the conffile before calling update-rc.d? It feels really bad to remove files from /etc in maintainer scripts, but perhaps it's the right thing to do... As an aside, I suppose that such manual removal would work both for file-rc and sysv-rc, right? Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html signature.asc Description: Digital signature
Re: Removing former conffiles
This one time, at band camp, Bas Wijnen said: Hello, After bug report #339387, I added a postinst file to the dummy package gnocatan-meta-server, which does update-rc.d gnocatan-meta-server remove /dev/null || true in order to get rid of the links which were created by the previous (non-dummy) version of the package. However, this didn't seem to work. Appearantly this is what happened: - The non-dummy package created the conffile - The package was upgraded to the dummy version, which no longer held the conffile. However, it being a conffile, it was not removed (perhaps this is only true if it was actually changed?) - On purging the dummy package, the conffile is not removed because it isn't listed as part of the package. - update-rc.d then refuses to remove the links, because the file is still there. - Both the conffile and the links remain on the system. Investigate the -f option of update-rc.d. There are various tricks around for getting rid of unwanted old conf files (check that the md5sum is unchanged and rm it if so, etc), but if you can safely just remove the links and be done with it, that's probably the simplest. The question is, how do I solve this? Should I forcefully remove the conffile before calling update-rc.d? It feels really bad to remove files from /etc in maintainer scripts, but perhaps it's the right thing to do... As an aside, I suppose that such manual removal would work both for file-rc and sysv-rc, right? I have no idea how they work, sorry. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Removing former conffiles
On Mon, Feb 06, 2006 at 09:21:28PM +0100, Bas Wijnen wrote: Hello, After bug report #339387, I added a postinst file to the dummy package gnocatan-meta-server, which does update-rc.d gnocatan-meta-server remove /dev/null || true in order to get rid of the links which were created by the previous (non-dummy) version of the package. However, this didn't seem to work. Appearantly this is what happened: - The non-dummy package created the conffile - The package was upgraded to the dummy version, which no longer held the conffile. However, it being a conffile, it was not removed (perhaps this is only true if it was actually changed?) - On purging the dummy package, the conffile is not removed because it isn't listed as part of the package. - update-rc.d then refuses to remove the links, because the file is still there. - Both the conffile and the links remain on the system. The question is, how do I solve this? Should I forcefully remove the conffile before calling update-rc.d? It feels really bad to remove files from /etc in maintainer scripts, but perhaps it's the right thing to do... It is fine to remove the conffile in purge. If you're handling a nonconffile config file, this is precisely what you [have to] do. You might also be interested in http://www.dpkg.org/ConffileHandling Also in some existing conffile prompts bugs: 335276 345112 304066 345113 346282 337992 and the message I sent to them about transferring conffile ownership. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing former conffiles
Bas Wijnen [EMAIL PROTECTED] wrote: The question is, how do I solve this? Should I forcefully remove the conffile before calling update-rc.d? It feels really bad to remove files from /etc in maintainer scripts, but perhaps it's the right thing to do... I've come across this several times, and what I did was - check the md5sum of the installed file * against the md5sum known to dpkg (not possible if the package was in rc state) * against known md5sums hardcoded into the maintainer script - if the file is unchanged, remove it - if it is changed, either keep it and insert a comment at its beginning that it is unused, or move/rename it. In all cases where the file's presence could have a bad effect, I renamed or moved it. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Removing former conffiles
On Mon, Feb 06, 2006 at 03:41:13PM -0500, pryzbyj wrote: On Mon, Feb 06, 2006 at 09:21:28PM +0100, Bas Wijnen wrote: Hello, After bug report #339387, I added a postinst file to the dummy package gnocatan-meta-server, which does update-rc.d gnocatan-meta-server remove /dev/null || true in order to get rid of the links which were created by the previous (non-dummy) version of the package. However, this didn't seem to work. Appearantly this is what happened: - The non-dummy package created the conffile - The package was upgraded to the dummy version, which no longer held the conffile. However, it being a conffile, it was not removed (perhaps this is only true if it was actually changed?) - On purging the dummy package, the conffile is not removed because it isn't listed as part of the package. - update-rc.d then refuses to remove the links, because the file is still there. - Both the conffile and the links remain on the system. The question is, how do I solve this? Should I forcefully remove the conffile before calling update-rc.d? It feels really bad to remove files from /etc in maintainer scripts, but perhaps it's the right thing to do... It is fine to remove the conffile in purge. If you're handling a nonconffile config file, this is precisely what you [have to] do. You might also be interested in http://www.dpkg.org/ConffileHandling Also in some existing conffile prompts bugs: 335276 345112 304066 345113 346282 337992 and the message I sent to them about transferring conffile ownership. I just read the bug log, and I like Steve's suggestion better. Check the upgrading-from version in postinst, and remove the files there. That way there aren't useless files before its purged, either. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing former conffiles
On Mon, Feb 06, 2006 at 10:02:06PM +0100, Frank K?ster wrote: Bas Wijnen [EMAIL PROTECTED] wrote: The question is, how do I solve this? Should I forcefully remove the conffile before calling update-rc.d? It feels really bad to remove files from /etc in maintainer scripts, but perhaps it's the right thing to do... - if the file is unchanged, remove it Even changed files are removed on purge. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing former conffiles
On Mon, 06 Feb 2006, Frank Küster wrote: - if it is changed, either keep it and insert a comment at its beginning that it is unused, or move/rename it. In all cases where the file's presence could have a bad effect, I renamed or moved it. Just a word of caution here: If the administrator has modified the file, you should not rename or move it, as they may know better than you what they're doing. A proper course of action would be warning them, and/or offering to remove the files in question via debconf. Additionally, you should check to make sure whether you're upgrading from a version after this transition; if that's the case, you shouldn't rename/delete either. Don Armstrong -- It was said that life was cheap in Ankh-Morpork. This was, of course, completely wrong. Life was often very expensive; you could get death for free. -- Terry Pratchet _Pyramids_ p25 http://www.donarmstrong.com http://rzlab.ucr.edu
conffiles no longer needed except ...
Hi! I have no idea how to properly handle the following situation: My package logwatch previously had all their configuration files in /etc/logwatch/conf. They were marked as conffiles so dpkg was responsible for policy-compliant upgrading. However, since version 7.0 logwatch has a very cool(TM) way to specify the configuration. There is a directory default.conf, containing the proposed upstream configuration, there is an optional dist.conf dir containing the debian specific modifications (both in /usr/share/logwatch/), and there is /etc/logwatch/conf, containing optional site-specific modifications. (the ./conf is there because upstream allows local scripts to be put in ./scripts ..) Now the issue is, that all the old files in /etc/logwatch/conf are no longer needed, except if it was customized. If it was not customized, they should be removed, because they will interfere with the configuration by me and upstream, especially when some changes are needed. The question is: How should they be removed? - Just by putting a warning in NEWS.Debian, telling the local admin to remove them except if he modified it. (A NEWS.Debian file will be needed anyway, so users don't stumble over the new layout) - Trying to figure out in the maintainer scripts if the file has been modified, and if it hasn't been modified, delete it? - Provide the local user a script he can optionally run to remove unneeded files (of course with a hint in README.Debian and NEWS.Debian) - another way? The current list of files: http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelistword=logwatchversion=unstablearch=all thanks for you replies Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
