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
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
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
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
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
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
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 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 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
21 matches
Mail list logo
