On 2021-01-03 09:02 +0900, Charles Plessy wrote:
> I have recently split the mime-support package in two: media-types and
> mailcap. But I wonder if I handled the conffiles correctly.
>
> mime-support had the conffiles `/etc/mime.types` and
> `/etc/mailcap.order` until version
Hello everybody,
and happy new year !
I have recently split the mime-support package in two: media-types and
mailcap. But I wonder if I handled the conffiles correctly.
mime-support had the conffiles `/etc/mime.types` and
`/etc/mailcap.order` until version 3.64. Version 3.65 is a transitional
Hi,
>However, after reading the manpage for dh_installdeb [4] (more
>specifically, the section `package.maintscript', I changed my mind and
>added lines such as:
>
> rm_conffile /etc/bash_completion.d/harbour 1:2.8-5~
>
>So... Is that the right thing to do? I.e. regardless of the version
>at wh
Hi, mentors,
I need help with the removal of obsolete conffiles in bash-completion.
I think I understood what to do, but since I don't know how to
reproduce the problem, I'm uncomfortable with the change. Below, I
give a long description of the problem (feel free to skip it if it
soun
Hi,
>OK, I see your point.
>
>In my usual, provocative style: To me, this means that the bug should be
>closed without further actions unless there is more input.
or change to usr/share, that seems a saner approach.
Your call, I don't have an opinion here!
G.
On 23/01/17 18:03, Gianfranco Costamagna wrote:
hello,
Hi!
However I think the .dist files
should be installed in /usr/share and copied from there instead of being
installed in /etc.
This is of course the Right Thing to do. Will implement, thanks!
This is nice, however I think this "
hello,
>> However I think the .dist files
>> should be installed in /usr/share and copied from there instead of being
>> installed in /etc.
>
>This is of course the Right Thing to do. Will implement, thanks!
This is nice, however I think this "workaround" should be dropped post-Stretch
releas
oops, happened to send the reply to James as a PM... here it comes, it
was actually meant for the list
Forwarded Message
Subject: Re: Adequate reports obsolete conffiles: and now what?
Date: Sat, 21 Jan 2017 16:40:10 +0100
From: Alec Leamas
To: James Cowgill
On 21/01/17
files are
> installed as e. g.,lirc_options.conf.dist. This file is updated but not
> used. If the actually used lirc_options.conf is missing it's created as
> a copy of the *dist file, but otherwise kept as-is.. In other words, I
> don't try to merge possible upstream changes, I j
Dear list,
The new, shiny lirc 0.9.4 has received a bug report #851618. At the
core, this is about adequate reporting
lirc: obsolete-conffile /etc/lirc/irexec.lircrc
lirc: obsolete-conffile /etc/lirc/lircmd.conf
lirc: obsolete-conffile /etc/lirc/hardware.conf
lirc: obsolete-conffile /etc/lirc
On Thu, May 09, 2013 at 01:49:48PM +0800, Paul Wise wrote:
> On Thu, May 9, 2013 at 1:08 PM, Bob Proulx wrote:
> > But of course many packages are difficult to purge.
>
> Every package must be possible to purge, if it is not possible then it
> is a release-critical issue and you should file a seve
e I filed:
http://bugs.debian.org/706911
And my template for that:
Subject:conffiles not removed
Usertags: conffile
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate
The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helpe
Paul Wise wrote:
> Please file bugs about obsolete conffiles when you find new ones. The
> packages themselves should clean up their obsolete conffiles.
Is there a bug example or two you could point me to so that I can
follow the standard template of reporting these problems? It appears
Paul Wise wrote:
> Bob Proulx wrote:
> > How can I as a system administrator clean that obsolete conffile up?
>
> rm -f /etc/some-obsolete-conffile
> apt-get --reinstall install package-that-provided-the-obsolete-conffile
Ah! Thanks. That works.
> > I have many obsolet
On Thu, May 9, 2013 at 1:08 PM, Bob Proulx wrote:
> I have many obsolete conffiles on my system.
Please file bugs about obsolete conffiles when you find new ones. The
packages themselves should clean up their obsolete conffiles. To help
with this task, you can install the package cal
I have many obsolete conffiles on my system. It has been upgraded
through many releases.
dpkg-query -W -f='${Conffiles}\n' | grep obsolete
Picking a simple one as an example:
/etc/skel/.bash_profile d1a8c44e7dd1bed2f3e75d1343b6e4e1 obsolete
If I purge the package and install it
Am 24.12.2011 12:23, schrieb David Kalnischkies:
> It's not only aptitude, every package manager using libapt will hate
> you for this - and therefore i will hate you; even on Christmas. ;)
I wouldn't want you to hate me. At least not on Christmas. ;-)
> In general, you should NEVER touch a file
of
> dpkg include 'dpkg-maintscript-helper' with commands to move or remove
> conffiles. This works nicely in Squeeze. But again, how can I support
> systems with Lenny? In order to make the transitional package forget
> about a conffile, I tested removing it in the package
Hello,
I am writing a transitional package to handle a software name change.
There are two problems I'm trying to handle:
- How to avoid marking the new package (which the transitional package
depends upon) as being autoinstalled.
- How to deal with old conffiles not adopted by the new pa
Ansgar Burchardt wrote:
> Sven Joachim wrote:
> > Bob Proulx wrote:
> >> I am hoping to understand the "obsolete" flag on conffiles in the dpkg
> >> status file. There are many packages that include this flag at the
> >> end of the line. For exam
Hi,
>> I am hoping to understand the "obsolete" flag on conffiles in the dpkg
>> status file. There are many packages that include this flag at the
>> end of the line. For example:
[...]
>
> They are obsolete because they no longer exist in the package. It is
On 2011-07-10 20:55 +0200, Bob Proulx wrote:
> I am hoping to understand the "obsolete" flag on conffiles in the dpkg
> status file. There are many packages that include this flag at the
> end of the line. For example:
>
> Package: file
> C
I am hoping to understand the "obsolete" flag on conffiles in the dpkg
status file. There are many packages that include this flag at the
end of the line. For example:
Package: file
Conffiles:
/etc/magic.mime 272913026300e7ae9b5e2d51f138e674 obsolete
n remove and purge and the
> > >> reason to use both, but removing unmodified conf files seems
^^
> > >> like a win to me. Keeps the clutter down.
> > >
> > > You'll stop thinking this when apt decides to
iles seems like a win to me.
> >> Keeps the clutter down.
> >
> > You'll stop thinking this when apt decides to do an upgrade as follows:
> >
> > 1. remove foo (and its conffiles)
> > 2. install bar
> > 3. install foo
> >
> > That is one of the
son to
>> use both, but removing unmodified conf files seems like a win to me.
>> Keeps the clutter down.
>
> You'll stop thinking this when apt decides to do an upgrade as follows:
>
> 1. remove foo (and its conffiles)
> 2. install bar
> 3. install foo
>
> That is
> Keeps the clutter down.
You'll stop thinking this when apt decides to do an upgrade as follows:
1. remove foo (and its conffiles)
2. install bar
3. install foo
That is one of the reasons for the current behavior, and temporarily
removing a package is how apt deals with certian de
ge but which only purges files which haven't been
> >> altered from the package's default?
> >
> > From what I understand, neither APT nor dpkg know if a file has
> > been modified since it has been installed.
>
> Well, dpkg stores the md5sum of conff
On Tue, 15 Feb 2011 14:06:20 -0800
Don Armstrong wrote:
> On Tue, 15 Feb 2011, Tony Houghton wrote:
> > It wouldn't be quite so bad if packages called update-rc.d disable
> > on their init scripts when removed so that init doesn't read the
> > disused scripts, but AFAICT from the Policy Manual (s
On Tue, Feb 15, 2011 at 4:06 PM, Don Armstrong wrote:
> On Tue, 15 Feb 2011, Tony Houghton wrote:
>> I don't like about it is that init scripts get left behind when
>> uninstalling packages.
>
> Configuration files are always left behind unless you purge a package.
Sure. That doesn't make it corr
On Tue, 15 Feb 2011, Tony Houghton wrote:
> I don't like about it is that init scripts get left behind when
> uninstalling packages.
Configuration files are always left behind unless you purge a package.
> It wouldn't be quite so bad if packages called update-rc.d disable
> on their init scripts
ackage's default?
>
> From what I understand, neither APT nor dpkg know if a file has been modified
> since it has been installed.
Well, dpkg stores the md5sum of conffiles in its database and thus knows
when they are modified, so removing unmodified conffiles would be
possible
"Jesús M. Navarro" writes:
> Anyway, my position would be that init script shouldn't have to be
> config files. For this to be true these steps should need to be worked
> on:
[...]
Given that nearly all of the Linux distribution work on init systems right
now is towards replacing the old Syste
On Tuesday 15 February 2011 15:16:27 Tony Houghton wrote:
> How about I file a wishlist bug for dpkg and apt for an option similar
> to purge but which only purges files which haven't been altered from the
> package's default?
From what I understand, neither APT nor dpkg know if a file has been mo
On Tue, 15 Feb 2011 16:33:25 +
Tony Houghton wrote:
> I was wondering, why are init scripts installed as conffiles? Is there a
> good reason other than that they're in /etc and nobody bothered to make
> an exception in debhelper?
>
> I would have thought it would be bet
On Tue, 15 Feb 2011, Tony Houghton wrote:
> I was wondering, why are init scripts installed as conffiles? Is
> there a good reason other than that they're in /etc and nobody
> bothered to make an exception in debhelper?
Anything that is in /etc should be editable by the admi
Hi
On Tuesday 15 February 2011, Jesús M. Navarro wrote:
> Hi, Michael:
>
> On Tuesday 15 February 2011 18:37:38 Michael Fladischer wrote:
> > Tony Houghton, 2011-02-15 17:33:
> > > I was wondering, why are init scripts installed as conffiles?
> >
> > Debain sw
ystem. So at least
every script should be overrideable by some script the admin supplies.
So what is the advantage of not having those files in /etc? (In
/etc/ they should be config files (ideally conffiles). If they are not
conffiles, they do not belong in /etc).
The advantage of having them in /e
Hi, Michael:
On Tuesday 15 February 2011 18:37:38 Michael Fladischer wrote:
> Tony Houghton, 2011-02-15 17:33:
> > I was wondering, why are init scripts installed as conffiles?
>
> Debain switched to dependency-based boot with Squeeze and those
> dependencies are controlled
Tony Houghton writes:
> I'd consider packages which require editing of the init script instead
> of using /etc/default or similar to be badly designed at best. I know
> fixing the mass of existing packages would be too big a job, but I
> thought it might be possible to provide a new option in dh_
On Tue, Feb 15, 2011 at 05:27:39PM +, Tony Houghton wrote:
> I'd consider packages which require editing of the init script instead
> of using /etc/default or similar to be badly designed at best. I know
> fixing the mass of existing packages would be too big a job, but I
> thought it might be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tony Houghton, 2011-02-15 17:33:
> I was wondering, why are init scripts installed as conffiles?
Debain switched to dependency-based boot with Squeeze and those
dependencies are controlled by the LSB headers inside each init script.
On the major
things like
> overriding/augmenting service start options or defining additional
> local service interdependencies. If policy were altered to make
> initscripts non-conffiles, tons of packages would be insta-buggy (at
> least from a wishlist standpoint, if not worse) due to the loss of
>
ies. If policy were altered to make
initscripts non-conffiles, tons of packages would be insta-buggy (at
least from a wishlist standpoint, if not worse) due to the loss of
admin flexibility.
Also, trying to change a major class of system controls which have
traditionally been considered conffiles to
I was wondering, why are init scripts installed as conffiles? Is there a
good reason other than that they're in /etc and nobody bothered to make
an exception in debhelper?
I would have thought it would be better to treat them as not to be
modified by the user/admin; any init configuration s
Regid Ichira writes:
> I have a Debian source package.
> By inspecting its content, how can I tell in advance which files will be
> recorded within DEBIAN/conffiles? Are there documents or URLs that
> discuss that question?
If you haven't read DebianPolicy and Debian Deve
On Sun, Feb 13, 2011 at 7:41 PM, Regid Ichira wrote:
> I have a Debian source package.
> By inspecting its content, how can I tell in advance which files will be
> recorded within DEBIAN/conffiles? Are there documents or URLs that
> discuss that question?
It depends on your pack
I have a Debian source package.
By inspecting its content, how can I tell in advance which files will be
recorded within DEBIAN/conffiles? Are there documents or URLs that
discuss that question?
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of
On Tue, Aug 31, 2010 at 06:47:09AM +0300, Zvi Dubitzky wrote:
> Is there a way to put something in DEBIAN directory that will trigger the
> poped up question when overwriting config files
> (during package installation) before running dpkg-deb --build to generate
> the packge OR is there a deb
to
> > generate the packge
>
> Yes, create DEBIAN/conffiles listing all the conffiles in the package.
There's also a way for dpkg and friends to merge old config file with new
config file without popping up questions which may be painful for your users.
This is the subje
Zvi Dubitzky writes:
> Is there a way to put something in DEBIAN directory that will trigger the
> poped up question when overwriting config files
> (during package installation) before running dpkg-deb --build to generate
> the packge
Yes, create DEBIAN/conffiles listing all t
dpkg-deb
thanks
Zvi Dubitzky
Email:d...@il.ibm.com
From: Russ Allbery
To: debian-mentors@lists.debian.org
Date: 31/08/2010 03:03
Subject:Re: conffiles
Matthew Palmer writes:
> On Mon, Aug 30, 2010 at 10:01:46PM +0300, Zvi Dubitzky wrote:
>> I am having conff
On Aug 30 2010, Russ Allbery wrote:
> Matthew Palmer writes:
> > You should never need to list files in /etc as conffiles, as they're
> > detected and a conffiles written out at package build time (because
> > Policy says all files in /etc are conffiles).
>
> T
Matthew Palmer writes:
> On Mon, Aug 30, 2010 at 10:01:46PM +0300, Zvi Dubitzky wrote:
>> I am having conffiles file placed in debian directory and holding the
>> configuration files ( full path) that should avoid being overwritten
>> when installing a package , Yet whe
On Mon, Aug 30, 2010 at 10:01:46PM +0300, Zvi Dubitzky wrote:
> I am having conffiles file placed in debian directory and holding the
> configuration files ( full path) that should avoid being overwritten when
> installing a package ,
> Yet when I install the built package the pa
Hi
I am having conffiles file placed in debian directory and holding the
configuration files ( full path) that should avoid being overwritten when
installing a package ,
Yet when I install the built package the package config files are
overwriting the existing config files at /etc
On Fre, 09 Feb 2007, Michael Biebl wrote:
> I have to get rid of the old conffile somehow (I formerly had two files
> foo and bar. In the new package version, the content of foo has been
> included in bar, so I want to get rid of foo, otherwise I get clashes).
Well the optimum solution is the foll
Hi list,
as you probably all know, conffiles from older package versions are kept
on package upgrades, even if the new package version does not ship the
conffile anymore.
How do I best get rid of such an old/obsolete conffile?
Simply delete it in preinst? Do I have to check if it was modified
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> This is the beauty of free software. If you find it so
> frustrating, write up a generic tool, and contribute it. And that
> would follow the grand old UNIX tradition of each command doing one
> thing well.
I may be of some help here.
I'
On Wed, 24 Jan 2007 12:52:53 +0100, Marc Haber
<[EMAIL PROTECTED]> said:
> I haven't thought about this in the necessary depth. To a newbie DD
> who has only been with Debian for six years it looks like ucf is not
> completely finished.
ucf scratches the itch I had to begin with, and it
t; >> <[EMAIL PROTECTED]> said:
> >> There is no need to fork ucf to create a command that provides
> >> functionality not in ucf.
>
> > the intersection between zmct (zugschlus' magical conffiles tool)
> > and ucf would be non-negligible and a lot
to create a command that provides
>> functionality not in ucf.
> the intersection between zmct (zugschlus' magical conffiles tool)
> and ucf would be non-negligible and a lot of routine stuff would
> need to be present in both packages.
err, why would there be anything non-negli
ay you have not learned how free software
> works.
Your opinion. Agree to disagree?
> There is no need to fork ucf to create a command that provides
> functionality not in ucf.
the intersection between zmct (zugschlus' magical conffiles tool) and
ucf would be non-negligible and a
On Sat, 20 Jan 2007 18:17:27 +0100, Marc Haber <[EMAIL PROTECTED]> said:
> On Sat, Jan 20, 2007 at 10:31:11AM -0600, Manoj Srivastava wrote:
>> This is the beauty of fre software. If you find it so frustrating,
>> write up a generic tool, and contribute it. And that would follow
>> the grand old
On Sat, Jan 20, 2007 at 10:31:11AM -0600, Manoj Srivastava wrote:
> This is the beauty of fre software. If you find it so
> frustrating, write up a generic tool, and contribute it. And that
> would follow the grand old UNIX tradition of each command doing one
> thing well.
The task at h
On Sat, 20 Jan 2007 10:47:16 +0100, Marc Haber
<[EMAIL PROTECTED]> said:
> Yes, that sounds sensible. It is, however, frustrating that there is
> no method (for example, offered by ucf) to do this without that much
> coding in maintainer scripts.
This is the beauty of fre software. If y
On Fri, Jan 19, 2007 at 10:28:41PM -0500, Justin Pryzby wrote:
> You will have to test with both sarge and etch dpkg (until after etch
> releases). Colin Watson recently wrote [0] about one of the ssh bugs
> and how this was complicated for him.
>
> You have to include the logic in the preinst, s
On Fri, Jan 19, 2007 at 09:43:04PM +0100, Santiago Vila wrote:
> On Fri, 19 Jan 2007, Marc Haber wrote:
> > I have a package with a bunch of configuration files that are managed
> > by my maintainer scripts and not by dpkg. I now need one of them
> > (a.conf) to vanish.
> >
> > How do I do this in
ile", as such term is reserved for "a conffile in the
dpkg sense". Yes, the subject is misleading. Please, people, don't
use the word conffile to refer to configuration files which are
not conffiles. Thanks :-)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Fri, Jan 19, 2007 at 09:34:28AM +0100, Marc Haber wrote:
> Hi,
>
> I have a package with a bunch of configuration files that are managed
> by my maintainer scripts and not by dpkg. I now need one of them
> (a.conf) to vanish.
>
> How do I do this in a clean way? I am thinking about the followi
Santiago Vila <[EMAIL PROTECTED]> wrote:
> Instead of 1,2,3 you could do 1,2,3 only when upgrading from a version
> previous than the one not having a.conf anymore
Sure.
> and in case that (3) happens, keep a.conf untouched, instead of
> renaming it (assuming the program will not read a.conf any
On Fri, 19 Jan 2007, Marc Haber wrote:
> Hi,
>
> I have a package with a bunch of configuration files that are managed
> by my maintainer scripts and not by dpkg. I now need one of them
> (a.conf) to vanish.
>
> How do I do this in a clean way? I am thinking about the following:
>
> (1) Let the
Hi,
I have a package with a bunch of configuration files that are managed
by my maintainer scripts and not by dpkg. I now need one of them
(a.conf) to vanish.
How do I do this in a clean way? I am thinking about the following:
(1) Let the new package version know about the md5sum of the last
Hi Mattia,
Op ma, 11-09-2006 te 21:01 +0200, schreef Mattia Dongili:
> Hello Mentors,
>
> to make the long story short this is an "how to deal existing conffiles
> and a new set of debconf questions to setup the package?" question.
>
> Now, the package is cpufr
Hello Mentors,
to make the long story short this is an "how to deal existing conffiles
and a new set of debconf questions to setup the package?" question.
Now, the package is cpufrequtils and what I'd like to achieve is
providing some nice debconf templates to configure
/etc/defau
t the distribution
> and also the Policy.
>
> Someone on #debian mentioned that symlinks can be included in the package
> file listing. If that's the case, can symlinks also be conffiles? Will
> dpkg make .dpkg-old symlinks and the like if the user changes the target o
can be included in the package
file listing. If that's the case, can symlinks also be conffiles? Will
dpkg make .dpkg-old symlinks and the like if the user changes the target of
the symlink?
Even if it works, is it not recommended because of some corner-case(s) dpkg
just isn't designed
change is lost after the next package upgrade.
>
> This should be an indication that you're not preserving administrator
> changes to configuration files if this occurs...
Err, no. If the conffiles are in /etc/bla.d/, the generated file
bla.conf is in /var/lib/bla/, and there'
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
y the administrator.
>>
>> No, I don't. The program reads its configuration from a file in
>> /var/lib/bla, but the conffiles (or configuration files) reside in
>> /etc/bla/bla.d.
>
> The configuration file is the file from which the configuration is
> read, that is
s configuration from a file in
> /var/lib/bla, but the conffiles (or configuration files) reside in
> /etc/bla/bla.d.
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. This
setup forces the administrator to us
> 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/lib/bla, but the conffiles (or configuration files) reside in
/etc/bla/bla.
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
>
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
(non-dummy) version of the package.
However, this didn't s
On Wed, Nov 23, 2005 at 10:50:47AM +0100, Willi Mann wrote:
> Hi!
>
> I have no idea how to properly handle the following situation: My
> package logwatch previously had all their configuration files in
> /etc/logwatch/conf. They were marked as conffiles so dpkg was
> resp
1 - 100 of 255 matches
Mail list logo
