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
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
sounds trivial
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
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 <leamas.a...@gmail.com>
To:
nstalled 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 just keep the *dist
> files
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
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 obsolete conffiles on my system
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
I have
://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-helper support
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 severity
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 fresh
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 called 'adequate
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
' 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's postinst script
and also remove the corresponding entry from
/var/lib
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 package
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 example:
[...]
They are obsolete because they no longer exist
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
/etc/magic 272913026300e7ae9b5e2d51f138e674
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
Conffiles:
/etc/magic.mime 272913026300e7ae9b5e2d51f138e674
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
the package maintainer's task to deal
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 should
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 non-conffile status
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
admin flexibility.
Also, trying to change a major class
-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 majority
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
Tony Houghton h...@realh.co.uk 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
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 by the LSB headers inside
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 /etc are:
- every user understands how to change them
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 switched to dependency-based boot with Squeeze
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 admin, and changes
respected
On Tue, 15 Feb 2011 16:33:25 +
Tony Houghton h...@realh.co.uk 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 better
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
Jesús M. Navarro jesus.nava...@undominio.net 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
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 in theory. However, the dpkg developers don't think
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
On Tue, Feb 15, 2011 at 4:06 PM, Don Armstrong d...@debian.org 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
On Tue, 15 Feb 2011 14:06:20 -0800
Don Armstrong d...@debian.org 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
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 conffiles in its database and thus
knows when they are modified, so removing unmodified
.
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 dependency issues.
Renaming a package
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 one of the reasons for the current behavior, and temporarily
removing a package
.
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
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 do an upgrade as
follows:
1. remove foo (and its conffiles)
2
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
On Sun, Feb 13, 2011 at 7:41 PM, Regid Ichira regi...@yahoo.com 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
Regid Ichira regi...@yahoo.com 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 Developer's
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 subject of one GSoC project this year. I'll
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
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 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 package config
Matthew Palmer mpal...@debian.org 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 when I install
On Aug 30 2010, Russ Allbery wrote:
Matthew Palmer mpal...@debian.org 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).
This is only true if you're
dpkg-deb
thanks
Zvi Dubitzky
Email:d...@il.ibm.com
From: Russ Allbery r...@debian.org
To: debian-mentors@lists.debian.org
Date: 31/08/2010 03:03
Subject:Re: conffiles
Matthew Palmer mpal...@debian.org writes:
On Mon, Aug 30, 2010 at 10:01:46PM +0300, Zvi Dubitzky wrote
Zvi Dubitzky d...@il.ibm.com 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
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
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
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've
:
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 of routine stuff would
need to be present in both packages.
err, why would there be anything
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
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: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 a clean
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, since
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 you
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 hand
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 UNIX
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 lot of routine stuff would need to
be present in both packages.
And, arguably
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-negligible beyond a
single grep call in common? I fail to see why
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
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 new
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
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 following:
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/default/cpufrequtils
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 cpufrequtils and what I'd like to achieve
.
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 of
the symlink?
Yes
Even if it works, is it not recommended because
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 for?
I'm using GMane
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's a symlink chain from
/usr/share/bla/bla.conf to /etc/bla.conf
there was
This would be a problem.
Why? What problem?
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
, 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 use a your special conffile setup
which they can't override.[1
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.
Why?
This
setup forces the administrator to use a your
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 silly
and
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
remove files from
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.
Just a
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
warning them,
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 the
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 course the
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 place your
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 administrator
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 can't assume that 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
than you
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
file, you
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
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
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 the
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 times,
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/null || true
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 perhaps
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
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
responsible for policy-compliant upgrading.
However, since version 7.0 logwatch has a very
1 - 100 of 237 matches
Mail list logo
