Josselin Mouette writes:
> Le dimanche 13 mai 2012 à 20:00 +0200, Gergely Nagy a écrit :
>> > There is a huge difference between gconf, for which you can set one
>> > specific setting in /etc, overriding the default in /usr (and in a way
>> > that will not break the application if the schemas ch
]] Stefan Fritsch
> For example, the apache2 init script starts htcacheclean if and only
> if mod_disk_cache is enabled. While this could arguably be considered
> as an upstrem deficiency, such cases won't simply disappear because
> systemd becomes more common.
Ideally, they will, but even if
On Tue, May 15, 2012 at 5:38 PM, Stefan Fritsch wrote:
> On Wednesday 09 May 2012, Gergely Nagy wrote:
>> > Apart from the fact that requirements will be different on
>> > different systems. Putting functionality for all possible corner
>> > cases into the daemon is not sensible for any upstream.
On Wednesday 09 May 2012, Gergely Nagy wrote:
> > Apart from the fact that requirements will be different on
> > different systems. Putting functionality for all possible corner
> > cases into the daemon is not sensible for any upstream.
>
> That is what configuration files and similar things are
On Tue, May 15, 2012 at 05:26:32PM +0200, Josselin Mouette wrote:
> Le dimanche 13 mai 2012 à 20:00 +0200, Gergely Nagy a écrit :
> > > There is a huge difference between gconf, for which you can set one
> > > specific setting in /etc, overriding the default in /usr (and in a way
> > > that will n
On Tue, May 15, 2012 at 05:26:32PM +0200, Josselin Mouette wrote:
Le dimanche 13 mai 2012 à 20:00 +0200, Gergely Nagy a écrit :
Not entirely true. You can override parts of the file too, without
copying: include the original. This doesn't let you override everything,
but for a lot of things, is
Le dimanche 13 mai 2012 à 20:00 +0200, Gergely Nagy a écrit :
> > There is a huge difference between gconf, for which you can set one
> > specific setting in /etc, overriding the default in /usr (and in a way
> > that will not break the application if the schemas change), and
> > systemd/udev, whi
Josselin Mouette writes:
> Le vendredi 11 mai 2012 à 11:25 +0200, Gergely Nagy a écrit :
>> Thomas Goirand writes:
>> > The fact that these files are in /lib and shouldn't be touched by the admin
>> > doesn't make them less configuration files. They still match the above
>> > definition from Wik
Le vendredi 11 mai 2012 à 11:25 +0200, Gergely Nagy a écrit :
> Thomas Goirand writes:
> > The fact that these files are in /lib and shouldn't be touched by the admin
> > doesn't make them less configuration files. They still match the above
> > definition from Wikipedia.
>
> Can I point you to /
Le vendredi 11 mai 2012 à 11:37 +0200, Tollef Fog Heen a écrit :
> I have /lib/systemd/system/foo.service and want to change something in
> it, I then create /etc/systemd/system/foo.service with a copy of the
> /lib one plus whatever changes I want.
>
> The version in /lib is then updated. How is
OoO Pendant le journal télévisé du samedi 12 mai 2012, vers 20:58,
Thomas Goirand disait :
>> The advantage of having the defaults in a file is that it makes it much
>> easier to inspect them. A .h file would typically not be installed, so
>> it wouldn't be readily available. In addition to
On 05/12/2012 10:02 PM, Nikolaus Rath wrote:
> The advantage of having the defaults in a file is that it makes it much
> easier to inspect them. A .h file would typically not be installed, so
> it wouldn't be readily available. In addition to that, it is much less
> expressive. The nice thing about
Thomas Goirand writes:
> On 05/11/2012 05:07 PM, Gergely Nagy wrote:
>> I'll turn this around: how do you handle cases where the defaults of
>> packages like apt, exim or syslogd change? Where the defaults are
>> embedded in the executable.
>>
> The thing is, if you put the default in a file, i
On Sat, May 12, 2012 at 05:25:57PM +0800, Thomas Goirand wrote:
> On 05/11/2012 05:07 PM, Gergely Nagy wrote:
> > I'll turn this around: how do you handle cases where the defaults of
> > packages like apt, exim or syslogd change? Where the defaults are
> > embedded in the executable.
> >
> The t
On 12.05.2012 11:21, Thomas Goirand wrote:
> By the way, I finally found the time to try systemd, and I was
> shocked to see how fast it booted! :)
> The only thing is that I had no clue what started: nothing were
> prompted on my screen. Is there a way to have it more verbose?
1/ Remove "quiet" f
On Sat, May 12, 2012 at 05:21:03PM +0800, Thomas Goirand wrote:
> By the way, I finally found the time to try systemd, and I was
> shocked to see how fast it booted! :)
> The only thing is that I had no clue what started: nothing were
> prompted on my screen. Is there a way to have it more verbose?
Thomas Goirand writes:
> On 05/12/2012 03:19 AM, Gergely Nagy wrote:
>> It's perfectly able to notice changes
>> in /lib/systemd too, or pretty much anywhere else.
>>
> I thought these were only default which we shouldn't
> have to care about?!? :)
You don't change defaults, but if you get no
Thomas Goirand writes:
> On 05/12/2012 03:29 AM, Gergely Nagy wrote:
>> It's not etc-overrides-lib that is the problem. It's defaults changing
>> without notice that is.
>
> Then, let me ask this:
> Do you expect that systemd's default in /lib will change often?
Nope.
> The only thing is that I
On 05/11/2012 05:07 PM, Gergely Nagy wrote:
> I'll turn this around: how do you handle cases where the defaults of
> packages like apt, exim or syslogd change? Where the defaults are
> embedded in the executable.
>
The thing is, if you put the default in a file, it's because you
expect these to
On 05/12/2012 03:29 AM, Gergely Nagy wrote:
> It's not etc-overrides-lib that is the problem. It's defaults changing
> without notice that is.
Then, let me ask this:
Do you expect that systemd's default in /lib will change often?
By the way, I finally found the time to try systemd, and I was
shoc
On 05/12/2012 03:19 AM, Gergely Nagy wrote:
> It's perfectly able to notice changes
> in /lib/systemd too, or pretty much anywhere else.
>
I thought these were only default which we shouldn't
have to care about?!? :)
Thomas
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
wi
On 05/12/2012 03:19 AM, Gergely Nagy wrote:
> The solution, however, is very simple: wrap dpkg calls, and have a list
> of files to watch for. Whenever a package touches a file that's on the
> list, fire a trigger, that can run a hook. Said hook can be something
> provided by etckeeper or similar,
On 05/12/2012 01:34 AM, Jean-Christophe Dubacq wrote:
> I think it would be really great to have some program being able to
> output all manual differences to all /etc files really useful for
> maintenance. I used to do that, but some rapidly evolving configuration
> files make it quickly unmaintai
Uoti Urpala wrote:
> George Danchev wrote:
[...]
>> For some reason or another the vast majority of applications have
>> not been following this approach. I'm not going to argue whether is
>> makes sense or not.
> The reason why most old applications do not follow that approach (at
> least not ye
* Steve Langasek [120511 16:17]:
> On Fri, May 11, 2012 at 11:08:32AM -0400, Marvin Renich wrote:
> > The FHS is very specific that /etc is for *Host-specific* system
>
> No, this is a total retcon. When the FHS was written, this was definitely
> NOT a shared understanding of a difference betwee
Steve Langasek writes:
> What *is* an issue is when upstreams decide to ship their defaults in
> /usr, but require users to duplicate information between /usr templates
> and /etc config files and ignore the contents of /usr in favor of the
> contents of /etc. This is also not a violation of FHS
On Fri, May 11, 2012 at 11:08:32AM -0400, Marvin Renich wrote:
> The FHS is very specific that /etc is for *Host-specific* system
> configuration, not upstream defaults or distribution-specific
> configuration. The clear intent is that this is where files that are
> intended to be modified by the
Tollef Fog Heen writes:
> ]] Gergely Nagy
>
>> Tollef Fog Heen writes:
>>
>> > ]] Gergely Nagy
>
>> >> In that case, the including file can be changed (by the admin) to be a
>> >> separate file, that does not include, and get the usual conffile
>> >> conflict dpkg prompt.
>> >
>> > How would
Thomas Goirand writes:
> On 05/11/2012 11:08 PM, Marvin Renich wrote:
>> For clarity, the etc-overrides-non-etc model that I am talking about is
>> where the file in /etc can override individual values, not where the
>> file in /etc must replace the entirety of the non-etc configuration.
>>
>
SEEWEB - Marco d'Itri writes:
> But this is a user error. The point is that with etc-overrides-lib there
> is no prompt at all when the upstream configuration changes.
Bzzt. There's no prompt ever when upstream defaults change. Unless *all*
the defaults are laid out in /etc, *AND* the user modi
OoO Peu avant le début de l'après-midi du vendredi 11 mai 2012, vers
13:20, Gergely Nagy disait :
>>> In other words, it does *exactly* the same thing systemd is
>>> criticised for.
>>>
>>
>> Which doesn't mean that it's a good practice.
> Tell me what you would gain, if there were no file
Thomas Goirand writes:
> On 05/11/2012 08:33 PM, Michael Biebl wrote:
>> Am 11.05.2012 14:30, schrieb Marco d'Itri:
>>
>>> The problem with etc-overrides-lib is that a file must be copied in
>>> full from /lib to /etc to be modified, and then future changes to the
>>> same file in /lib will
m...@linux.it (Marco d'Itri) writes:
> On May 11, Thomas Goirand wrote:
>
>> > Long story short, I still don't see what the fuss is about.
>> The fuss is about we're being told that there will be silent
>> overwriting of configuration files without being prompted about
>> changes, which potential
Thomas Goirand writes:
> Seriously, can't someone who broke his configuration wget the package,
> and use mc to get into the .deb and get the original configuration
> file???
FWIW, I'd love an easier way to keep track of my /etc, where upstream
changes and my own are on a separate branch. So the
On 11/05/2012 19:03, Thomas Goirand wrote:
> On 05/12/2012 12:22 AM, Jean-Christophe Dubacq wrote:
>> I find your attitude assumes users always have the knowledge and the
>> time to investigate everything. This is not the reality.
>>
>> Sincerly,
>>
> Not at all. Anyone without the knowledge wil
On 05/12/2012 12:22 AM, Jean-Christophe Dubacq wrote:
> I find your attitude assumes users always have the knowledge and the
> time to investigate everything. This is not the reality.
>
> Sincerly,
>
Not at all. Anyone without the knowledge will not be able to
restore anything anyway.
Anyone wi
On 05/11/2012 11:08 PM, Marvin Renich wrote:
> For clarity, the etc-overrides-non-etc model that I am talking about is
> where the file in /etc can override individual values, not where the
> file in /etc must replace the entirety of the non-etc configuration.
>
This case is much much more accep
On 11/05/2012 15:29, Thomas Goirand wrote:
> The setting of unix rights 0440 is indeed very amusing.
Yes. Maybe the mean to chmod a-w everything, for some applications will
not work with so large modes (sudo, for example).
> The only nice point about this proposal is that it's going to make happ
Thomas Goirand writes:
> Section 10.7.2 of dpm:
> "Any configuration files created or used by your package must reside in
> |/etc|."
"Configuration file" is a term of art that is previously defined in the
Policy document. It doesn't mean what you're taking it to mean.
There isn't anything abo
* Thomas Goirand [120511 04:45]:
> On 05/11/2012 04:04 AM, David Weinehall wrote:
> From: http://en.wikipedia.org/wiki/Configuration_file
>
> "In computing, configuration files, or config files configure the initial
> settings for some computer programs. They are used for user applications,
> ser
m...@linux.it (Marco d'Itri) writes:
> On May 11, Nikolaus Rath wrote:
>
>> > Wrong: since you have to copy the whole file to override it, and files
>> > in /lib have no conffiles handling, after an upgrade you will not know
>> > what was changed by you and what was changed upstream.
>> I think
On 05/11/2012 07:04 PM, Gergely Nagy wrote:
> Steve McIntyre writes:
>
>
>> Jean-Christophe Dubacq wrote:
>>
>>> If dpkg kept a copy of the original configuration file (to be retrieved
>>> at all times), it would be easier to spot local changes.
>>> I use etckeeper to do that, but it's a b
On 05/11/2012 08:28 PM, David Weinehall wrote:
> Talking about yourself in pluralis majestatis now?
> Yes, I get it that you are. Or are you somehow assuming that you can
> speak for all of Debian? I guess you're aware of the fact that I'm a DD
> too?
>
By reading other replies, I thought ther
On 05/11/2012 08:33 PM, Michael Biebl wrote:
> Am 11.05.2012 14:30, schrieb Marco d'Itri:
>
>> The problem with etc-overrides-lib is that a file must be copied in
>> full from /lib to /etc to be modified, and then future changes to the
>> same file in /lib will be ignored (so maybe the package
On 05/11/2012 08:30 PM, Marco d'Itri wrote:
> On May 11, Thomas Goirand wrote:
>
>
>>> Long story short, I still don't see what the fuss is about.
>>>
>> The fuss is about we're being told that there will be silent
>> overwriting of configuration files without being prompted about
>> cha
On May 11, Michael Biebl wrote:
> You can either copy the file or use the .include directive (which was
> already mentioned) and only override the settings you need.
Not with udev or kmod.
> > The problem with etc-overrides-lib is that a file must be copied in
> > full from /lib to /etc to be m
]] Gergely Nagy
> Tollef Fog Heen writes:
>
> > ]] Gergely Nagy
> >> In that case, the including file can be changed (by the admin) to be a
> >> separate file, that does not include, and get the usual conffile
> >> conflict dpkg prompt.
> >
> > How would that work?
> >
> > I have /lib/systemd
Am 11.05.2012 14:30, schrieb Marco d'Itri:
> The problem with etc-overrides-lib is that a file must be copied in
> full from /lib to /etc to be modified, and then future changes to the
> same file in /lib will be ignored (so maybe the package will break
> because these changes are required, etc)
Thomas Goirand writes:
> On 05/11/2012 06:39 PM, Gergely Nagy wrote:
>> Long story short, I still don't see what the fuss is about.
>>
> The fuss is about we're being told that there will be silent
> overwriting of configuration files without being prompted about
> changes, which potentially,
Am 11.05.2012 14:30, schrieb Marco d'Itri:
> The problem with etc-overrides-lib is that a file must be copied in
> full from /lib to /etc to be modified, and then future changes to the
> same file in /lib will be ignored (so maybe the package will break
> because these changes are required, etc)
]] Thomas Goirand
> On 05/11/2012 06:39 PM, Gergely Nagy wrote:
> > Long story short, I still don't see what the fuss is about.
> >
> The fuss is about we're being told that there will be silent
> overwriting of configuration files without being prompted about
> changes, which potentially, wil
On May 11, Thomas Goirand wrote:
> > Long story short, I still don't see what the fuss is about.
> The fuss is about we're being told that there will be silent
> overwriting of configuration files without being prompted about
> changes, which potentially, will make it horrible to manage
> upgrade
On May 11, Gergely Nagy wrote:
> Long story short, I still don't see what the fuss is about.
Apparently the reason is that you do not understand the problem, since
you keep getting back to the not relevant issue of software which
supports placing configuration directives in multiple directories
On Fri, May 11, 2012 at 04:39:22PM +0800, Thomas Goirand wrote:
[snip]
>
> From: http://en.wikipedia.org/wiki/Configuration_file
>
> "In computing, configuration files, or config files configure the initial
> settings for some computer programs. They are used for user applications,
> server proce
Philip Hands wrote:
> The traditional Debian approach to /etc is largely self documenting, to
> the extent that one can generally walk into a site cold and (having
> established that they have decent backups) cheerfully do an upgrade on
> their Debian servers without anything breaking (I do this re
Thomas Goirand writes:
> On 05/11/2012 06:39 PM, Gergely Nagy wrote:
>>In other words, it does *exactly* the same thing systemd is
>>criticised for.
>>
>
> Which doesn't mean that it's a good practice.
Tell me what you would gain, if there were no files under /lib/systemd,
and all of
Thomas Goirand writes:
> On 05/11/2012 04:52 PM, Gergely Nagy wrote:
>> Neither the FHS, nor the policy says anything about etc-overrides-lib as
>> far as I can see. Neither pro or con. Do feel free to point me to the
>> relevant section, would I be mistaken.
>>
>
> Section 10.7.2 of dpm:
>
>
Steve McIntyre writes:
> Jean-Christophe Dubacq wrote:
>>
>>If dpkg kept a copy of the original configuration file (to be retrieved
>>at all times), it would be easier to spot local changes.
>>I use etckeeper to do that, but it's a bit tiresome to isolate all local
>>changes (I have to save the d
On 05/11/2012 06:39 PM, Gergely Nagy wrote:
> Long story short, I still don't see what the fuss is about.
>
The fuss is about we're being told that there will be silent
overwriting of configuration files without being prompted about
changes, which potentially, will make it horrible to manage
upg
On 05/11/2012 06:39 PM, Gergely Nagy wrote:
>In other words, it does *exactly* the same thing systemd is
>criticised for.
>
Which doesn't mean that it's a good practice.
Thomas
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble
On 05/11/2012 05:25 PM, Gergely Nagy wrote:
> And in etc-overrides-lib, config files still remain in /etc.
No.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4facf398
On 05/11/2012 04:52 PM, Gergely Nagy wrote:
> Neither the FHS, nor the policy says anything about etc-overrides-lib as
> far as I can see. Neither pro or con. Do feel free to point me to the
> relevant section, would I be mistaken.
>
Section 10.7.2 of dpm:
"Any configuration files created or u
Stephan Seitz writes:
> On Fri, May 11, 2012 at 10:52:25AM +0200, Gergely Nagy wrote:
>>Neither the FHS, nor the policy says anything about etc-overrides-lib as
>>far as I can see. Neither pro or con. Do feel free to point me to the
>>relevant section, would I be mistaken.
>
> To be honest, I sti
m...@linux.it (Marco d'Itri) writes:
> On May 11, Gergely Nagy wrote:
>
>> And in etc-overrides-lib, config files still remain in /etc. Its just
>> the defaults that live elsewhere. That the defaults are files, and are
>> under /lib, is an implementation detail, similarly how gconf defaults
>> li
Jean-Christophe Dubacq wrote:
>
>If dpkg kept a copy of the original configuration file (to be retrieved
>at all times), it would be easier to spot local changes.
>I use etckeeper to do that, but it's a bit tiresome to isolate all local
>changes (I have to save the diffs somewhere) (and a lost hope
Stephan Seitz writes:
> On Fri, May 11, 2012 at 11:25:10AM +0200, Gergely Nagy wrote:
>>Are you happy with dropping a snippet into a conf.d/ directory, and your
>>software breaking on an upgrade without notice? Because that can happen
>>even now, with software that uses only /etc, and /etc alone
On Fri, May 11, 2012 at 12:07:55PM +0200, Jean-Christophe Dubacq wrote:
BTW, for standard workstations, there is less and less need to change
things in /etc. My current quota is 1346 files in /etc for about 30 of
them with local changes. This is quite a bad signal/noise ratio.
Well, a standard
On 11/05/2012 08:47, Vincent Bernat wrote:
> OoO Pendant le journal télévisé du jeudi 10 mai 2012, vers 20:29,
> Jean-Christophe Dubacq disait :
>
>> I do not know about trivially merging changes in the etc-overrides-lib
>> model, but in the current model, I am presented with the dpkg prom
Tollef Fog Heen writes:
> ]] Gergely Nagy
>
>> Tollef Fog Heen writes:
>>
>> > ]] Uoti Urpala
>> >
>> > Hi,
>> >
>> >> Wrong: as mentioned in this thread before, one of the advantages of the
>> >> etc-overrides-lib model is the option of having a file in /etc that
>> >> first includes the one
On Fri, May 11, 2012 at 11:25:10AM +0200, Gergely Nagy wrote:
Are you happy with dropping a snippet into a conf.d/ directory, and your
software breaking on an upgrade without notice? Because that can happen
even now, with software that uses only /etc, and /etc alone for their
configuration, witho
On Fri, May 11, 2012 at 10:52:25AM +0200, Gergely Nagy wrote:
Neither the FHS, nor the policy says anything about etc-overrides-lib as
far as I can see. Neither pro or con. Do feel free to point me to the
relevant section, would I be mistaken.
To be honest, I still don’t really understand what
On May 11, Gergely Nagy wrote:
> And in etc-overrides-lib, config files still remain in /etc. Its just
> the defaults that live elsewhere. That the defaults are files, and are
> under /lib, is an implementation detail, similarly how gconf defaults
> live under /usr/share/gconf/defaults.
This is n
Thomas Goirand writes:
> From: http://en.wikipedia.org/wiki/Configuration_file
>
> "In computing, configuration files, or config files configure the initial
> settings for some computer programs. They are used for user applications,
> server processes and operating system settings."
>
> The fact
]] Gergely Nagy
> Tollef Fog Heen writes:
>
> > ]] Uoti Urpala
> >
> > Hi,
> >
> >> Wrong: as mentioned in this thread before, one of the advantages of the
> >> etc-overrides-lib model is the option of having a file in /etc that
> >> first includes the one in /lib, then overrides just one part
Philip Hands writes:
> On Thu, 10 May 2012 21:30:56 +0300, Uoti Urpala
> wrote:
>> Marco d'Itri wrote:
>> > On May 10, Bjørn Mork wrote:
>> >
>> > > Agree. Copying a large set of default policies into /etc just because
>> > > they *can* be overridden is not user friendly. And it does not ma
Tollef Fog Heen writes:
> ]] Uoti Urpala
>
> Hi,
>
>> Wrong: as mentioned in this thread before, one of the advantages of the
>> etc-overrides-lib model is the option of having a file in /etc that
>> first includes the one in /lib, then overrides just one particular
>> value. This allows handlin
Thomas Goirand writes:
> On 05/11/2012 12:53 AM, Uoti Urpala wrote:
>> The reason why most old applications do not follow that approach (at
>> least not yet) is pretty obvious: their authors never considered it.
>> etc-overrides-lib semantics have only become a seriously considered
>> alternative
On 05/11/2012 04:04 AM, David Weinehall wrote:
> On Fri, May 11, 2012 at 02:44:45AM +0800, Thomas Goirand wrote:
>
>> On 05/10/2012 04:52 AM, Steve McIntyre wrote:
>>
>>> No, really - please *do* do this. The fact that a lot of the software
>>> coming out of RedHat development seems to be d
On 05/11/2012 12:53 AM, Uoti Urpala wrote:
> The reason why most old applications do not follow that approach (at
> least not yet) is pretty obvious: their authors never considered it.
> etc-overrides-lib semantics have only become a seriously considered
> alternative fairly recently.
>
No.
The
On Thu, 10 May 2012 21:30:56 +0300, Uoti Urpala wrote:
> Marco d'Itri wrote:
> > On May 10, Bjørn Mork wrote:
> >
> > > Agree. Copying a large set of default policies into /etc just because
> > > they *can* be overridden is not user friendly. And it does not make the
> > > defaults any more co
On May 11, Nikolaus Rath wrote:
> > Wrong: since you have to copy the whole file to override it, and files
> > in /lib have no conffiles handling, after an upgrade you will not know
> > what was changed by you and what was changed upstream.
> I think everyone here agrees with that. The interest
OoO Pendant le journal télévisé du jeudi 10 mai 2012, vers 20:29,
Jean-Christophe Dubacq disait :
> I do not know about trivially merging changes in the etc-overrides-lib
> model, but in the current model, I am presented with the dpkg prompt
> about conffiles for some programs where I adde
]] Uoti Urpala
Hi,
> Wrong: as mentioned in this thread before, one of the advantages of the
> etc-overrides-lib model is the option of having a file in /etc that
> first includes the one in /lib, then overrides just one particular
> value. This allows handling more updates without needing manua
Don Armstrong writes:
> On Thu, 10 May 2012, Gergely Nagy wrote:
>> FWIW, /etc/default/* and /etc/$package/conf.d/* and similar already
>> do something *very* close to what etc-overrides-non-etc does. To the
>> point that changing a file under /etc/default, or adding a snippet
>> to conf.d/ can b
On Thu, May 10, 2012 at 09:56:57PM +0100, Ben Hutchings wrote:
> On Thu, May 10, 2012 at 10:55:06AM -0700, Don Armstrong wrote:
> > On Thu, 10 May 2012, Uoti Urpala wrote:
> > > You're pretty much just saying that dpkg and helpers like ucf have
> > > implemented better functionality than rpm. I don
m...@linux.it (Marco d'Itri) writes:
> On May 10, Bjørn Mork wrote:
>
>> Agree. Copying a large set of default policies into /etc just because
>> they *can* be overridden is not user friendly. And it does not make the
>> defaults any more configuration either. It just hides important local
>> ch
On Friday 11 May 2012 00:01:14 Uoti Urpala wrote:
--cut--
> > You need to at least start reading some man-pages (a good start would be
> > ucf(1), ucfr(1), ucfq(1), debconf-devel(7)) before keep jamming
> > suggestion like "improvements to be able to alert the user about
> > changes". This is alrea
Don Armstrong wrote:
> On Thu, 10 May 2012, Ben Hutchings wrote:
> > In the etc-overrides-lib model, program defaults and local
> > configuration are effectively being merged every time the program
> > starts.
This seems to assume that the program would always read both. systemd
unit files don't w
On Thu, 10 May 2012, Gergely Nagy wrote:
> FWIW, /etc/default/* and /etc/$package/conf.d/* and similar already
> do something *very* close to what etc-overrides-non-etc does. To the
> point that changing a file under /etc/default, or adding a snippet
> to conf.d/ can break just as well when the und
On Thu, 10 May 2012, Ben Hutchings wrote:
> In the etc-overrides-lib model, program defaults and local
> configuration are effectively being merged every time the program
> starts.
This is only the case if the configuration files are fine grained
enough that overrides to a configuration file would
On May 10, Jean-Christophe Dubacq wrote:
> There are cases where file in /etc overrides only the directives present
> in /etc and not the rest. I prefer this way.
Fine, but they are not the cases which we are discussing.
--
ciao,
Marco
signature.asc
Description: Digital signature
George Danchev wrote:
> On Thursday 10 May 2012 21:46:41 Uoti Urpala wrote:
> > I don't see how the following would make this comparison with rpm relevant.
>
> It was a comparison of the packaging system facilities to handle upgrades of
> the configuration files of the applications. This was init
On Thu, 10 May 2012 20:29:05 +0200, Jean-Christophe Dubacq wrote:
> in the current model, I am presented with the dpkg prompt
> about conffiles for some programs where I added (or changed) only one
> line (off the top of my head: only the servers list in roundcube, for
> example), and dpkg does no
On Thu, May 10, 2012 at 10:55:06AM -0700, Don Armstrong wrote:
> On Thu, 10 May 2012, Uoti Urpala wrote:
> > You're pretty much just saying that dpkg and helpers like ucf have
> > implemented better functionality than rpm. I don't see how that's
> > relevant to the discussion.
>
> The reason why i
On Fri, May 11, 2012 at 02:44:45AM +0800, Thomas Goirand wrote:
> On 05/10/2012 04:52 AM, Steve McIntyre wrote:
> > No, really - please *do* do this. The fact that a lot of the software
> > coming out of RedHat development seems to be designed solely for their
> > use, including working around the
On Thursday 10 May 2012 21:46:41 Uoti Urpala wrote:
> Don Armstrong wrote:
> > On Thu, 10 May 2012, Uoti Urpala wrote:
> > > You're pretty much just saying that dpkg and helpers like ucf have
> > > implemented better functionality than rpm. I don't see how that's
> > > relevant to the discussion.
>
Don Armstrong writes:
> On Thu, 10 May 2012, Uoti Urpala wrote:
>> Don Armstrong wrote:
>> > The reason why it is relevant is because [...]
>>
>> I don't see how the following would make this comparison with rpm
>> relevant.
>
> This is debian-devel, and we're talking about configuration file
>
George Danchev wrote:
> On Thursday 10 May 2012 19:53:18 Uoti Urpala wrote:
> > The reason why most old applications do not follow that approach (at
> > least not yet) is pretty obvious: their authors never considered it.
> > etc-overrides-lib semantics have only become a seriously considered
> > a
On Thu, 10 May 2012, Uoti Urpala wrote:
> Don Armstrong wrote:
> > The reason why it is relevant is because [...]
>
> I don't see how the following would make this comparison with rpm
> relevant.
This is debian-devel, and we're talking about configuration file
handling in Debian, which makes ucf
On 10/05/2012 21:12, Don Armstrong wrote:
> On Thu, 10 May 2012, Jean-Christophe Dubacq wrote:
>> I do not know about trivially merging changes in the
>> etc-overrides-lib model, but in the current model, I am presented
>> with the dpkg prompt about conffiles for some programs where I added
>> (or
1 - 100 of 289 matches
Mail list logo
