]] 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
Josselin Mouette j...@debian.org 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
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, which
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
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 not break
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 for, I
On Tue, May 15, 2012 at 5:38 PM, Stefan Fritsch s...@sfritsch.de 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
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 the
Le vendredi 11 mai 2012 à 11:25 +0200, Gergely Nagy a écrit :
Thomas Goirand z...@debian.org 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
Josselin Mouette j...@debian.org writes:
Le vendredi 11 mai 2012 à 11:25 +0200, Gergely Nagy a écrit :
Thomas Goirand z...@debian.org 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
Uoti Urpala uoti.urp...@pp1.inet.fi 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
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
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 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
with
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
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
Thomas Goirand z...@debian.org 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
Thomas Goirand z...@debian.org 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
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?
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 from
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 thing is,
Thomas Goirand z...@debian.org 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
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
OoO Pendant le journal télévisé du samedi 12 mai 2012, vers 20:58,
Thomas Goirand z...@debian.org 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
Don Armstrong d...@debian.org 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
]] 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 manual
OoO Pendant le journal télévisé du jeudi 10 mai 2012, vers 20:29,
Jean-Christophe Dubacq jean-christophe.dub...@ens-lyon.org 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
On May 11, Nikolaus Rath nikol...@rath.org 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.
On Thu, 10 May 2012 21:30:56 +0300, Uoti Urpala uoti.urp...@pp1.inet.fi wrote:
Marco d'Itri wrote:
On May 10, Bjørn Mork bj...@mork.no 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
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 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 designed
Thomas Goirand z...@debian.org 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
Tollef Fog Heen tfh...@err.no 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
Philip Hands p...@hands.com writes:
On Thu, 10 May 2012 21:30:56 +0300, Uoti Urpala uoti.urp...@pp1.inet.fi
wrote:
Marco d'Itri wrote:
On May 10, Bjørn Mork bj...@mork.no wrote:
Agree. Copying a large set of default policies into /etc just because
they *can* be overridden is not
]] Gergely Nagy
Tollef Fog Heen tfh...@err.no 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
Thomas Goirand z...@debian.org 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.
On May 11, Gergely Nagy alger...@balabit.hu 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
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 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,
Tollef Fog Heen tfh...@err.no writes:
]] Gergely Nagy
Tollef Fog Heen tfh...@err.no 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
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 jean-christophe.dub...@ens-lyon.org disait :
I do not know about trivially merging changes in the etc-overrides-lib
model, but in the current model, I am
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
Stephan Seitz stse+deb...@fsing.rootsland.net 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
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 if
m...@linux.it (Marco d'Itri) writes:
On May 11, Gergely Nagy alger...@balabit.hu 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
Stephan Seitz stse+deb...@fsing.rootsland.net 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
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 used
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:
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 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
Steve McIntyre st...@einval.com 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
Thomas Goirand z...@debian.org 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:
Thomas Goirand z...@debian.org 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
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
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 processes
On May 11, Gergely Nagy alger...@balabit.hu 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
On May 11, Thomas Goirand z...@debian.org 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
]] 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, will make
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 z...@debian.org 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
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).
]] Gergely Nagy
Tollef Fog Heen tfh...@err.no 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
On May 11, Michael Biebl bi...@debian.org 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
On 05/11/2012 08:30 PM, Marco d'Itri wrote:
On May 11, Thomas Goirand z...@debian.org 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
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 will
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 there
On 05/11/2012 07:04 PM, Gergely Nagy wrote:
Steve McIntyre st...@einval.com 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
m...@linux.it (Marco d'Itri) writes:
On May 11, Nikolaus Rath nikol...@rath.org 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
* Thomas Goirand z...@debian.org [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
Thomas Goirand z...@debian.org 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
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 happy
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
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 with
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 will not be
Thomas Goirand z...@debian.org 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
m...@linux.it (Marco d'Itri) writes:
On May 11, Thomas Goirand z...@debian.org 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
Thomas Goirand z...@debian.org 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
OoO Peu avant le début de l'après-midi du vendredi 11 mai 2012, vers
13:20, Gergely Nagy alger...@balabit.hu 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
SEEWEB - Marco d'Itri m...@seeweb.it 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*
Thomas Goirand z...@debian.org 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.
Tollef Fog Heen tfh...@err.no writes:
]] Gergely Nagy
Tollef Fog Heen tfh...@err.no 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
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
Steve Langasek vor...@debian.org 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
* Steve Langasek vor...@debian.org [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
On Wed, May 09, 2012 at 12:46:40PM -0700, Josh Triplett wrote:
It also means that I don't get a pile of noise in etckeeper from all the
upgrades of default configurations, so that my commits to etckeeper primarily
consist of my own local changes.
I don't personally use etckeeper but it strikes
Uoti Urpala uoti.urp...@pp1.inet.fi writes:
Machine-specific configuration belongs in /etc. The default behavior of
the tools doesn't.
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
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 missing/broken features of RPM,
I'm curious exactly what you mean by this, since my own
On Thursday 10 May 2012 00:22:11 Uoti Urpala wrote:
Steve McIntyre wrote:
Josh Triplett wrote:
Marco d'Itri wrote:
The more I think about it, the more I suspect that the correct
solution would be to just symlink /lib/udev/rules.d/ to
/etc/udev/rules.d/ and so on.
Please don't.
George Danchev wrote:
On Thursday 10 May 2012 00:22:11 Uoti Urpala wrote:
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 missing/broken
On Wed, May 09, 2012 at 03:47:21PM +0200, Gergely Nagy wrote:
Tollef Fog Heen tfh...@err.no writes:
]] Philipp Kern
You will not, however, get a conffile update prompt when the system
file changes (e.g. to update your own local copy to incorporate the
fix).
This is something I'm
On May 10, Bjørn Mork bj...@mork.no 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
changes and makes it difficult both
On 10/05/2012 19:34, Marco d'Itri wrote:
On May 10, Bjørn Mork bj...@mork.no 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
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 it is relevant is because in the etc-overrides-lib
model you are unable to
On Thursday 10 May 2012 19:53:18 Uoti Urpala wrote:
George Danchev wrote:
On Thursday 10 May 2012 00:22:11 Uoti Urpala wrote:
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
On 10/05/2012 19:55, 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 it is relevant is because in the
On 05/10/2012 12:14 AM, Uoti Urpala wrote:
Not having the files in /etc by default does have technical advantages.
It's easier to see what is local non-default configuration. Original
default file is always available in a known location (and very easy to
revert to, temporarily for testing or
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 missing/broken features of RPM, is
seriously annoying. Configuration
Marco d'Itri wrote:
On May 10, Bjørn Mork bj...@mork.no 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
changes
On Thu, 10 May 2012, David Weinehall wrote:
On Wed, May 09, 2012 at 03:47:21PM +0200, Gergely Nagy wrote:
Such a tool would certainly be very useful, but doing it right would be
fairly hard, as far as I see.
And it would require assistance from at least the package maintainer, to
mark
On 05/10/2012 07:01 AM, Fernando Lemos wrote:
I've seen people mention that the way udev and systemd do config files
is really motivated by limitations in RH's packaging tools. Maybe
that's the case, maybe not.
It's *not*! It's a difference in *policy*. :)
RH's policy is that you should never
1 - 100 of 289 matches
Mail list logo
