On Thu, 12 Nov 2015 10:24:48 -0800, Nikolaus Rath
wrote:
>On Nov 11 2015, Marc Haber wrote:
>> Once and for all we're doing _SOMETHING_ right, let's keep it that
>> way.
>
>I think what Debian is doing right is that it tracks and notifies about
>changes in configuration files. But that doesn't me
On Thursday 12 November 2015 23:14:16 you wrote:
> Ok. I was thinking wrong. I was under the impression that cme used
> the original LCDd.conf.
The wiki page is not clear enough then. I'll modify it.
> Yes. I'm always a bit relunctant to not check that the merge of my
> modif and upstream modif w
On Thu, Nov 12, 2015 at 11:08:04PM +0100, Vincent Danjean wrote:
You can also find database in text files with a checksum so you cannot
modify them by hand (I am looking at the cn=config slapd database
here).
In a future slapd revision I hope to move those to /var, as they are in
practice inte
On Fri, Nov 13, 2015 at 2:47 AM, Josh Triplett wrote:
> While I still think etckeeper makes sense (and works even better) with
> only admin changes kept in /etc, I'd certainly love it if I could tell
> exactly what's *unique* about a given system by looking at the tiny
> handful of files in /etc.
Le 12/11/2015 18:36, Dominique Dumont a écrit :
> Hello Vincent
>
> On Wednesday 11 November 2015 17:11:13 Vincent Danjean wrote:
>> I looked at [2] (cme seems really powerfull to offer automatic
>> upgrade/merge of config files). I've two questions after reading the wiki:
>>
>> 1) I vaguely rec
Le 11/11/2015 21:58, Jean-Christophe Dubacq a écrit :
> I don't even want to speak about the /etc files that act as cache data
> and config mixed together (I am looking at you, CUPS).
You can also find database in text files with a checksum so you cannot
modify them by hand (I am looking at the cn
Josselin Mouette wrote:
> Marc Haber wrote:
> On Wed, 11 Nov 2015 21:58:13 +0100, Jean-Christophe Dubacq
> wrote:
> >[ ? 11/11/2015 18:14 ] [ ? Marc Haber ]
> >> Once and for all we're doing _SOMETHING_ right, let's keep it that
> >> way.
> >I do not agree
On Nov 11 2015, Marc Haber wrote:
> Once and for all we're doing _SOMETHING_ right, let's keep it that
> way.
I think what Debian is doing right is that it tracks and notifies about
changes in configuration files. But that doesn't mean we have
implemented it in the right (or best) way.
I think t
On Wed, Nov 11, 2015 at 04:52:06PM +0100, Dominique Dumont wrote:
> A file delivered by a package in /etc automatically becomes a conffiles.
If you use debhelper.
(not saying you shouldn't, but hey, sometimes being pedantic is good)
--
It is easy to love a country that is famous for chocolate a
Hello Vincent
On Wednesday 11 November 2015 17:11:13 Vincent Danjean wrote:
> I looked at [2] (cme seems really powerfull to offer automatic
> upgrade/merge of config files). I've two questions after reading the wiki:
>
> 1) I vaguely recall recommendations/requirement that a package
> should
[ ⏰ 11/11/2015 23:28 ] [ ✎ Jeroen Dekkers ]
> Documentation should be put in /usr/share/doc, not in /etc. I always
> find it annoying to have to review lots of comment changes in
> configuration files during upgrades instead of simply the options that
> actually changed. With big config files it of
Marc Haber wrote:
On Wed, 11 Nov 2015 21:58:13 +0100, Jean-Christophe Dubacq
wrote:
>[ ? 11/11/2015 18:14 ] [ ? Marc Haber ]
>> Once and for all we're doing _SOMETHING_ right, let's keep it that
>> way.
>I do not agree that we are doing something exactly r
At Wed, 11 Nov 2015 18:14:26 +0100,
Marc Haber wrote:
>
> On Wed, 11 Nov 2015 17:29:31 +0100, Ole Streicher
> wrote:
> >Paul Wise writes:
> >> I expect systemd users in other distributions would appreciate a
> >> feature to track changes in the default configuration too.
> >
> >Many programs hav
On Wed, Nov 11, 2015 at 4:23 PM, Bjørn Mork wrote:
> Bjørn Mork writes:
>>
>> "/usr/lib/sysctl.d/" is systemd specific. Dropping files there won't do
>> anything unless you run the systemd-sysctl service.
>
> Sorry, should have researched this better first. sysctl WILL use
> "/usr/lib/sysctl.d
On Wed, Nov 11, 2015 at 4:16 PM, Bjørn Mork wrote:
> Tom H writes:
>>
>> systemd isn't the first package to allow/promote shipping distro
>> settings in "/lib" or "/usr/lib" and overriding them via "/etc"; udev
>> and polkit/policykit have behaved like this for a long time. There's
>> also "/usr/
On Wed, 11 Nov 2015 21:58:13 +0100, Jean-Christophe Dubacq
wrote:
>[ ? 11/11/2015 18:14 ] [ ? Marc Haber ]
>> Once and for all we're doing _SOMETHING_ right, let's keep it that
>> way.
>I do not agree that we are doing something exactly right. I would like
>/etc to only contain what I changed (as
[ ⏰ 11/11/2015 18:14 ] [ ✎ Marc Haber ]
> Once and for all we're doing _SOMETHING_ right, let's keep it that
> way.
I do not agree that we are doing something exactly right. I would like
/etc to only contain what I changed (as a sysadmin), and nothing else ;
AND I would like to be warned if somethi
2015-11-11 1:03 GMT+01:00 Vincent Danjean :
> Hi,
>
> Le 10/11/2015 14:49, Andrew Shadura a écrit :
>> I think you can try to do it systemd way: keep the default configuration
>> in /usr/lib, and leave /etc for local user configuration which overrides
>> the default config.
>>
>> Not sure how goo
Jakub Wilk wrote:
> Also, how I am supposed to know that I can customize /etc/foobar.conf
> if /etc/foobar.conf doesn't even exist?
Because you want to modify the behavior of foobar, and "man foobar"
references foobar.conf.
- Josh Triplett
On Wed, 11 Nov 2015 17:29:31 +0100, Ole Streicher
wrote:
>Paul Wise writes:
>> On Wed, Nov 11, 2015 at 10:38 PM, Ian Jackson wrote:
>> I expect systemd users in other distributions would appreciate a
>> feature to track changes in the default configuration too.
>
>Many programs have builtin defau
On Thu, Nov 12, 2015 at 12:29 AM, Ole Streicher wrote:
> Paul Wise writes:
>> I expect systemd users in other distributions would appreciate a
>> feature to track changes in the default configuration too.
>
> Many programs have builtin defaults that are used when they are not
> overwritten by a con
Paul Wise writes:
> On Wed, Nov 11, 2015 at 10:38 PM, Ian Jackson wrote:
> I expect systemd users in other distributions would appreciate a
> feature to track changes in the default configuration too.
Many programs have builtin defaults that are used when they are not
overwritten by a configurati
On Wed, 11 Nov 2015 16:55:27 +0100
Marc Haber wrote:
> On Wed, 11 Nov 2015 15:38:18 +0100, Tom H wrote:
> >systemd isn't the first package to allow/promote shipping distro
> >settings in "/lib" or "/usr/lib" and overriding them via "/etc"; udev
> >and polkit/policykit have behaved like this for
Hi,
Le 11/11/2015 16:52, Dominique Dumont a écrit :
> On the other hand, if your post-inst script creates a configuration file in
> /etc, this file is not handled by dpkg and is not a conffile.
>
> That's what I did for to be able to upgrade automatically lcdproc
> configuration [2] by cme in
On Wed, 11 Nov 2015 15:38:18 +0100, Tom H wrote:
>systemd isn't the first package to allow/promote shipping distro
>settings in "/lib" or "/usr/lib" and overriding them via "/etc"; udev
>and polkit/policykit have behaved like this for a long time.
Pötteringware, of course. And that doesn't make i
On Wed, 11 Nov 2015 14:38:42 +, Ian Jackson
wrote:
>Anyway, that systemd.deb does it wrong, definitely doesn't mean that
>we should repeat the same mistake for other programs.
Agreed.
Greetings
Marc
--
-- !! No courtesy copies, please !! -
Marc Haber
Le mardi 10 novembre 2015, 12:42:21 12:42:21 Alec Leamas a écrit :
> Also: updating the new config files, systemd or /etc/lirc/*, in
> maintainer scripts is not allowed [1] (?)
Not exactly. You're confusing "configuration file" and "conffile" (*). Both
can exists in /etc/. The latter is handled b
Bjørn Mork writes:
> "/usr/lib/sysctl.d/" is systemd specific. Dropping files there won't do
> anything unless you run the systemd-sysctl service.
Sorry, should have researched this better first. sysctl WILL use
"/usr/lib/sysctl.d/" if it exists. procps won't create it, but it is
supported.
Tom H writes:
> systemd isn't the first package to allow/promote shipping distro
> settings in "/lib" or "/usr/lib" and overriding them via "/etc"; udev
> and polkit/policykit have behaved like this for a long time. There's
> also "/usr/lib/sysctl.d/" where a distro ship settings that can be
> ov
On Wed, Nov 11, 2015 at 10:38 PM, Ian Jackson wrote:
> That doesn't mean we shouldn't think about whether we can transition
> to a better arrangement for systemd in Debian.
I expect systemd users in other distributions would appreciate a
feature to track changes in the default configuration too.
Le 11/11/2015 15:31, Alec Leamas a écrit :
> On 11/11/15 15:17, Vincent Danjean wrote:
>> Le 11/11/2015 10:37, Alec Leamas a écrit :
>>> However, it touches one possible route: to store the original vendor
>>> files separately and create the actually used config files in postinst.
>> ucf has been w
Marc Haber writes ("Re: Putting default config files in /usr [was; (newbie)
Disruptive LIRC package update.]"):
> On Wed, 11 Nov 2015 13:59:24 +0100, Mat wrote:
> >This is one strong key point of
> >Debian versus most other distribs. Please don't change that.
&g
On Wed, Nov 11, 2015 at 10:37 AM, Marc Haber
wrote:
>
> I violently disagree. We have always done it the other way, and had
> the advantage that our conffile handling (which used to be and IMO
> still is far superior to everything else other distributions have)
> could notice if _both_ local chang
On 11/11/15 15:17, Vincent Danjean wrote:
Le 11/11/2015 10:37, Alec Leamas a écrit :
However, it touches one possible route: to store the original vendor
files separately and create the actually used config files in postinst.
ucf has been written for this. Do not reinvent the wheel, use ucf.
Le 11/11/2015 10:37, Alec Leamas a écrit :
> However, it touches one possible route: to store the original vendor
> files separately and create the actually used config files in postinst.
ucf has been written for this. Do not reinvent the wheel, use ucf.
The doc even provides info about how to mov
On Wed, 11 Nov 2015 13:59:24 +0100, Mat wrote:
>This is one strong key point of
>Debian versus most other distribs. Please don't change that.
For systemd, this change is already done. Noone cared.
Greetings
Marc
--
-- !! No courtesy copies, please !! -
Ma
On 11/11/15 13:28, Marc Haber wrote:
On Wed, 11 Nov 2015 11:04:01 +0100, Alec Leamas
wrote:
On 11/11/15 10:37, Marc Haber wrote:
On Tue, 10 Nov 2015 18:24:52 -0800, Josh Triplett
wrote:
Vincent Danjean wrote:
I violently disagree. We have always done it the other way, and had
the advantag
On Wed, 11 Nov 2015 11:04:01 +0100, Alec Leamas wrote:
> BTW, note that the /etc/systemd/system local overrides don't need to be
> complete files, just the things locally changed. systemd merges the /lib
> and /etc files to the actual unit.
To expand on Marc's example, let's say /lib/systemd/sys
+1
Debian has been doing a really good job at managing configuration files
for years (dpkg, ucf). It gives the sysadmin complete visibility on
changes and flexibility in actions. This is one strong key point of
Debian versus most other distribs. Please don't change that.
On 11/11/15 10:37, Marc
* Vincent Danjean , 2015-11-11, 01:03:
I think you can try to do it systemd way: keep the default
configuration in /usr/lib, and leave /etc for local user configuration
which overrides the default config.
Not sure how good is this idea, I hope others can comment on this.
For myself, I find t
On Wed, 11 Nov 2015 11:04:01 +0100, Alec Leamas
wrote:
>On 11/11/15 10:37, Marc Haber wrote:
>> On Tue, 10 Nov 2015 18:24:52 -0800, Josh Triplett
>> wrote:
>>> Vincent Danjean wrote:
>
>> I violently disagree. We have always done it the other way, and had
>> the advantage that our conffile handli
On 11/11/15 10:37, Marc Haber wrote:
> On Tue, 10 Nov 2015 18:24:52 -0800, Josh Triplett
> wrote:
>> Vincent Danjean wrote:
> I violently disagree. We have always done it the other way, and had
> the advantage that our conffile handling (which used to be and IMO
> still is far superior to everyth
On 10/11/15 14:49, Andrew Shadura wrote:
> On 10/11/15 13:39, Alec Leamas wrote:
>> On 10/11/15 13:26, Andrew Shadura wrote:
>>
I think migrating from old config to a new config in a postinst is okay
as long as you keep the old config and complain to the user that a
manual verificati
On Tue, 10 Nov 2015 18:24:52 -0800, Josh Triplett
wrote:
>Vincent Danjean wrote:
>> Le 10/11/2015 14:49, Andrew Shadura a écrit :
>> > I think you can try to do it systemd way: keep the default configuration
>> > in /usr/lib, and leave /etc for local user configuration which overrides
>> > the def
On Wed, Nov 11, 2015 at 10:24 AM, Josh Triplett wrote:
> As for versioning of changes to the defaults, I hope someday to see all
> package contents stored and distributed via version control, making it
> easy to track changes even across versions I haven't actually installed
> on my system.
The W
Vincent Danjean wrote:
> Le 10/11/2015 14:49, Andrew Shadura a écrit :
> > I think you can try to do it systemd way: keep the default configuration
> > in /usr/lib, and leave /etc for local user configuration which overrides
> > the default config.
> >
> > Not sure how good is this idea, I hope ot
Hi,
Le 10/11/2015 14:49, Andrew Shadura a écrit :
> I think you can try to do it systemd way: keep the default configuration
> in /usr/lib, and leave /etc for local user configuration which overrides
> the default config.
>
> Not sure how good is this idea, I hope others can comment on this.
On 10/11/15 14:49, Andrew Shadura wrote:
> On 10/11/15 13:39, Alec Leamas wrote:
>> On 10/11/15 13:26, Andrew Shadura wrote:
> I think you can try to do it systemd way: keep the default configuration
> in /usr/lib, and leave /etc for local user configuration which overrides
> the default config.
>
On 10/11/15 13:39, Alec Leamas wrote:
> On 10/11/15 13:26, Andrew Shadura wrote:
>
>> > I think migrating from old config to a new config in a postinst is okay
>> > as long as you keep the old config and complain to the user that a
>> > manual verification may be needed.
>> >
>> > As least ifupdo
On 10/11/15 12:42, Alec Leamas wrote:
> On 09/11/15 17:44, Alec Leamas wrote:
>> > On 08/11/15 19:28, Dominique Dumont wrote:
>>> >> On Sunday 08 November 2015 15:19:30 Alec Leamas wrote:
>> > So, this is a change, yes. But in the long run, wouldn't we be better
>> > off by sticking to upstream's w
On 10/11/15 13:26, Andrew Shadura wrote:
> I think migrating from old config to a new config in a postinst is okay
> as long as you keep the old config and complain to the user that a
> manual verification may be needed.
>
> As least ifupdown did that a couple of times, and nobody complained :)
On 09/11/15 17:44, Alec Leamas wrote:
> On 08/11/15 19:28, Dominique Dumont wrote:
>> On Sunday 08 November 2015 15:19:30 Alec Leamas wrote:
> So, this is a change, yes. But in the long run, wouldn't we be better
> off by sticking to upstream's way of doing it instead of running a
> separate Debia
On 08/11/15 19:28, Dominique Dumont wrote:
> On Sunday 08 November 2015 15:19:30 Alec Leamas wrote:
>> Some tooling to build the new configuration from the old will indeed be
>> required. This is actually some work - it includes a complete lircd
>> command line parser with ~18 options. But it's cer
Le dimanche 8 novembre 2015, 19:28:38 Dominique Dumont a écrit :
>
> If I rephrase, with the current setup, 'service lirc start' starts 4 daemon
> processes.
>
> Which means the user only has to type one command to start and stop all of
> them.
>
> With the new setup. the user will have to deal
On Sunday 08 November 2015 15:19:30 Alec Leamas wrote:
> Some tooling to build the new configuration from the old will indeed be
> required. This is actually some work - it includes a complete lircd
> command line parser with ~18 options. Bit it's certainly doable.
Good to know
> The real reason
On 07/11/15 10:05, Dominique Dumont wrote:
> On Friday 06 November 2015 18:48:29 Alec Leamas wrote:
>> So, an upgrade will not support hardware.conf. Which basically breaks
>> each and every installation. While we could (i. e., should) provide docs
>> and perhaps some tooling to ease the process,
On Friday 06 November 2015 18:48:29 Alec Leamas wrote:
> So, an upgrade will not support hardware.conf. Which basically breaks
> each and every installation. While we could (i. e., should) provide docs
> and perhaps some tooling to ease the process,
Well, you can provide a tools to upgrade from h
Hi Alec,
Quoting Alec Leamas (2015-11-06 18:48:29)
> I am in the process on creating a new lirc packaging. The core reason
> is that current debian version is stalled at 0.9.0 as of 2011 whereas
> the upstream version is 0.9.3, with 0.9.4 under way. My plan is to try
> to package 0.9.4.
>
> Be
Dear list,
I am in the process on creating a new lirc packaging. The core reason is
that current debian version is stalled at 0.9.0 as of 2011 whereas the
upstream version is 0.9.3, with 0.9.4 under way. My plan is to try to
package 0.9.4.
Besides the more practical issues here is a big configura
59 matches
Mail list logo
