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
