Don Armstrong <[EMAIL PROTECTED]> wrote:
>> People who forgot (or never noticed) that the file is generated from
>> files in conf.d will open /etc/texmf/bla.conf in their favorite
>> editor, change the generated file without noticing, and will be
>> surprised if the change is lost after the next p
On Wed, 08 Feb 2006, Frank Küster wrote:
> Don Armstrong <[EMAIL PROTECTED]> wrote:
> > The configuration file is the file from which the configuration is
> > read, that is, the file in /var/lib/blah which isn't in /etc.
[...]
> > 1: In the sense that they can't decide that using the conf.d is sill
Don Armstrong <[EMAIL PROTECTED]> wrote:
> On Wed, 08 Feb 2006, Frank Küster wrote:
>> Don Armstrong <[EMAIL PROTECTED]> wrote:
>> > You've now got a conffile in a location which is not /etc, namely
>> > /var/lib/bla, which cannot be overridden by the administrator.
>>
>> No, I don't. The program
On Wed, 08 Feb 2006, Frank Küster wrote:
> Don Armstrong <[EMAIL PROTECTED]> wrote:
> > You've now got a conffile in a location which is not /etc, namely
> > /var/lib/bla, which cannot be overridden by the administrator.
>
> No, I don't. The program reads its configuration from a file in
> /var/li
Don Armstrong <[EMAIL PROTECTED]> wrote:
> On Tue, 07 Feb 2006, Frank Küster wrote:
>> Don Armstrong <[EMAIL PROTECTED]> wrote:
>> > On Tue, 07 Feb 2006, Frank Küster wrote:
>> >> Don Armstrong <[EMAIL PROTECTED]> wrote:
>> >>
>> >> > Right. The problem is that it's not always easy to know if the
On Tue, Feb 07, 2006 at 11:47:49PM +0100, Bas Wijnen wrote:
> On Tue, Feb 07, 2006 at 12:28:39AM -0800, Don Armstrong wrote:
> > On Tue, 07 Feb 2006, Frank K?ster wrote:
> > > Don Armstrong <[EMAIL PROTECTED]> wrote:
> > > > Just a word of caution here: If the administrator has modified the
> > > >
On Tue, Feb 07, 2006 at 12:28:39AM -0800, Don Armstrong wrote:
> On Tue, 07 Feb 2006, Frank K?ster wrote:
> > Don Armstrong <[EMAIL PROTECTED]> wrote:
> > > Just a word of caution here: If the administrator has modified the
> > > file, you should not rename or move it, as they may know better
> > >
On Tue, 07 Feb 2006, Frank Küster wrote:
> Don Armstrong <[EMAIL PROTECTED]> wrote:
> > On Tue, 07 Feb 2006, Frank Küster wrote:
> >> Don Armstrong <[EMAIL PROTECTED]> wrote:
> >>
> >> > Right. The problem is that it's not always easy to know if the file
> >> > will no longer be read at all; you c
On Tue, Feb 07, 2006 at 11:35:01AM -0800, Don Armstrong wrote:
> On Tue, 07 Feb 2006, Frank K?ster wrote:
> > Don Armstrong <[EMAIL PROTECTED]> wrote:
> >
> > > Right. The problem is that it's not always easy to know if the file
> > > will no longer be read at all; you can't assume that the admini
Don Armstrong <[EMAIL PROTECTED]> wrote:
> On Tue, 07 Feb 2006, Frank Küster wrote:
>> Don Armstrong <[EMAIL PROTECTED]> wrote:
>>
>> > Right. The problem is that it's not always easy to know if the file
>> > will no longer be read at all; you can't assume that the administrator
>> > has left in
On Tue, 07 Feb 2006, Frank Küster wrote:
> Don Armstrong <[EMAIL PROTECTED]> wrote:
>
> > Right. The problem is that it's not always easy to know if the file
> > will no longer be read at all; you can't assume that the administrator
> > has left in place your default configuration system.
>
> Of
Don Armstrong <[EMAIL PROTECTED]> wrote:
> Right. The problem is that it's not always easy to know if the file
> will no longer be read at all; you can't assume that the administrator
> has left in place your default configuration system.
Of course the maintainer should know their package. If th
On Tue, 07 Feb 2006, Frank Küster wrote:
> Don Armstrong <[EMAIL PROTECTED]> wrote:
> > Just a word of caution here: If the administrator has modified the
> > file, you should not rename or move it, as they may know better
> > than you what they're doing. A proper course of action would be
> > warn
Don Armstrong <[EMAIL PROTECTED]> wrote:
> On Mon, 06 Feb 2006, Frank Küster wrote:
>> - if it is changed, either keep it and insert a comment at its
>> beginning that it is unused, or move/rename it. In all cases where
>> the file's presence could have a bad effect, I renamed or moved
>> it
Justin Pryzby <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 06, 2006 at 10:02:06PM +0100, Frank K?ster wrote:
>> Bas Wijnen <[EMAIL PROTECTED]> wrote:
>>
>> > The question is, how do I solve this? Should I forcefully remove
>> > the conffile before calling update-rc.d? It feels really bad to
>> > re
On Mon, 06 Feb 2006, Frank Küster wrote:
> - if it is changed, either keep it and insert a comment at its
> beginning that it is unused, or move/rename it. In all cases where
> the file's presence could have a bad effect, I renamed or moved
> it.
Just a word of caution here: If the administr
On Mon, Feb 06, 2006 at 10:02:06PM +0100, Frank K?ster wrote:
> Bas Wijnen <[EMAIL PROTECTED]> wrote:
>
> > The question is, how do I solve this? Should I forcefully remove
> > the conffile before calling update-rc.d? It feels really bad to
> > remove files from /etc in maintainer scripts, but p
On Mon, Feb 06, 2006 at 03:41:13PM -0500, pryzbyj wrote:
> On Mon, Feb 06, 2006 at 09:21:28PM +0100, Bas Wijnen wrote:
> > Hello,
> >
> > After bug report #339387, I added a postinst file to the dummy package
> > gnocatan-meta-server, which does
> > update-rc.d gnocatan-meta-server remove &>/dev/n
Bas Wijnen <[EMAIL PROTECTED]> wrote:
> The question is, how do I solve this? Should I forcefully remove the conffile
> before calling update-rc.d? It feels really bad to remove files from /etc in
> maintainer scripts, but perhaps it's the right thing to do...
I've come across this several time
On Mon, Feb 06, 2006 at 09:21:28PM +0100, Bas Wijnen wrote:
> Hello,
>
> After bug report #339387, I added a postinst file to the dummy package
> gnocatan-meta-server, which does
> update-rc.d gnocatan-meta-server remove &>/dev/null || true
> in order to get rid of the links which were created by
This one time, at band camp, Bas Wijnen said:
> Hello,
>
> After bug report #339387, I added a postinst file to the dummy package
> gnocatan-meta-server, which does
> update-rc.d gnocatan-meta-server remove &>/dev/null || true
> in order to get rid of the links which were created by the previous
>
21 matches
Mail list logo
