Re: Init scripts as conffiles

[Tony Houghton]

On Tue, 15 Feb 2011 17:04:10 -0600
"Boyd Stephen Smith Jr."  wrote:

> On Tuesday 15 February 2011 16:44:49 Matt Zagrabelny wrote:
> > On Tue, Feb 15, 2011 at 4:39 PM, Joey Hess  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

Re: Init scripts as conffiles

[Boyd Stephen Smith Jr.]

On Tuesday 15 February 2011 16:44:49 Matt Zagrabelny wrote:
> On Tue, Feb 15, 2011 at 4:39 PM, Joey Hess  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

[Matt Zagrabelny]

On Tue, Feb 15, 2011 at 4:39 PM, Joey Hess  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

[Joey Hess]

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

[Tony Houghton]

On Tue, 15 Feb 2011 22:50:53 +0100
Sven Joachim  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

[Tony Houghton]

On Tue, 15 Feb 2011 14:06:20 -0800
Don Armstrong  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

[Matt Zagrabelny]

On Tue, Feb 15, 2011 at 4:06 PM, Don Armstrong  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

[Don Armstrong]

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

[Sven Joachim]

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

[Russ Allbery]

"Jesús M. Navarro"  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)   


--
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

[Boyd Stephen Smith Jr.]

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

[Tony Houghton]

On Tue, 15 Feb 2011 16:33:25 +
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?
> 
> 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

[Don Armstrong]

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

[Stefan Lippers-Hollmann]

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

[Bernhard R. Link]

* Jesús M. Navarro  [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. 

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

[Jesús M. Navarro]

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

[Russ Allbery]

Tony Houghton  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)   


-- 
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

[The Fungi]

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

[Michael Fladischer]

-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

[Tony Houghton]

On Tue, 15 Feb 2011 17:05:41 +
The Fungi  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

[The Fungi]

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

Init scripts as conffiles

[Tony Houghton]

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