On 25 February 2018 at 22:42, Don Armstrong wrote:
> On Sun, 25 Feb 2018, Dimitri John Ledkov wrote:
>> A couple of conffiles were /etc/X11/Xsession.d/00upstart and
>> /etc/X11/Xsession.d/99upstart which assumed that upstart would be
>> alwasy be available, and in bionic afte
On Sun, Feb 25, 2018 at 04:18:45PM -0800, Don Armstrong wrote:
> On Mon, 26 Feb 2018, Michael Biebl wrote:
> > So dpkg would have to remember if a conffile was removed by the admin
> > prior to the uninstallation. Doesn't sound too complicated to me, we
> > already have an obsolete flag in the stat
On Mon, 26 Feb 2018, Michael Biebl wrote:
> Basically, every package which allows to be extended by other packages
> via .d directories is affected.
>
> Take logrotated as a example and the dance e.g. rsyslog has to do in
> preinst/postrm.
Heh; I should have known that this hack already existed.
Am 25.02.2018 um 23:42 schrieb Don Armstrong:
> On Sun, 25 Feb 2018, Dimitri John Ledkov wrote:
>> A couple of conffiles were /etc/X11/Xsession.d/00upstart and
>> /etc/X11/Xsession.d/99upstart which assumed that upstart would be
>> alwasy be available, and in bionic afte
On Sun, 25 Feb 2018, Dimitri John Ledkov wrote:
> A couple of conffiles were /etc/X11/Xsession.d/00upstart and
> /etc/X11/Xsession.d/99upstart which assumed that upstart would be
> alwasy be available, and in bionic after the above described update
> started to error out, and preve
Recently, in Ubuntu we have discovered the following upgrade fallout.
On xenial -> bionic upgrades, upstart binary package was removed but
not purged. As it's no longer needed for the installation, and upstart
binary package is no longer shipped in bionic.
However, the conffiles are left
be found with a
> >> ".dpkg-old" suffix then.
> >
> > This is I guess, an extended misconception, --force-confmiss will only
> > install missing conffiles if they are missing AND the conffile changes
> > in the new package relative to the one installed (
On Wed, 30 Nov 2016 13:20:43 +0100, Simon Richter
wrote:
>Hi,
>
>On Wed, Nov 30, 2016 at 12:19:42PM +0100, Marc Haber wrote:
>
>[Restoring deleted conffiles]
>
>> dpkg --force-confmiss --install , as suggested by Simon,
>> didn't work
>
>Hm, that sm
ng configuration files, but not overwrite changed ones. If some
>> configuration files were damaged, you can use "--force-confnew" to
>> unpack all configuration files; your old files can be found with a
>> ".dpkg-old" suffix then.
>
> This is I guess, an extend
ration files, but not overwrite changed ones. If some
> > configuration files were damaged, you can use "--force-confnew" to
> > unpack all configuration files; your old files can be found with a
> > ".dpkg-old" suffix then.
>
> This is I guess, an extend
nfiguration files were damaged, you can use "--force-confnew" to
> unpack all configuration files; your old files can be found with a
> ".dpkg-old" suffix then.
This is I guess, an extended misconception, --force-confmiss will only
install missing conffiles if they are mis
On Wed, 2016-11-30 at 13:20 +0100, Simon Richter wrote:
> Hi,
>
> On Wed, Nov 30, 2016 at 12:19:42PM +0100, Marc Haber wrote:
>
> [Restoring deleted conffiles]
>
> > dpkg --force-confmiss --install , as suggested by Simon,
> > didn't work
>
> Hm, tha
Am 30.11.2016 um 13:20 schrieb Simon Richter:
> Hi,
>
> On Wed, Nov 30, 2016 at 12:19:42PM +0100, Marc Haber wrote:
>
> [Restoring deleted conffiles]
>
>> dpkg --force-confmiss --install , as suggested by Simon,
>> didn't work
>
> Hm, that smells
Hi,
On Wed, Nov 30, 2016 at 12:19:42PM +0100, Marc Haber wrote:
[Restoring deleted conffiles]
> dpkg --force-confmiss --install , as suggested by Simon,
> didn't work
Hm, that smells like a bug.
Simon
On Wed, 2016-11-30 at 12:16 +, Ian Campbell wrote:
> I think it would be really cool if etckeeper could create and maintain
> a dpkg-dist branch with all the pristine stuff in it, no idea what
> hooks or integration would be needed for that though!
Oh, looks like I'm not the only one:
http
On Wed, 2016-11-30 at 12:54 +0100, Ansgar Burchardt wrote:
> Hi Svante,
>
> On Tue, 2016-11-29 at 17:58 +0100, Svante Signell wrote:
> >
> > After upgrading to sid the conffiles don't seem to be installed any
> > longer?
>
> I think it would be nice to mak
Hi Svante,
On Tue, 2016-11-29 at 17:58 +0100, Svante Signell wrote:
> After upgrading to sid the conffiles don't seem to be installed any
> longer?
I think it would be nice to make restoring the original configuration
easier. The various --force-conf* options by dpkg are not easily
ial and important packages is that you can only reinstall
>them. So apt-get install --reinstall or dpkg -i only reinstalls
>the package, not the conffiles. Now I know how to get the conffiles back, but
>tracing which packages has them is hard: Any ideas?
dpkg --force-confmiss --install , a
Sorry for empty messages, but my mailer: evolution has gone nuts after the
upgrade and recovery :(
On Wed, 2016-11-30 at 11:56 +0100, Svante Signell wrote:
>
On Tue, 2016-11-29 at 19:18 +0100, Simon Richter wrote:
> Hi,
>
> On 29.11.2016 17:58, Svante Signell wrote:
>
> > After upgrading to sid the conffiles don't seem to be installed any longer?
> > Examples are bash, passwd, basefiles and libpam-runtime. Especially t
On Wed, Nov 30, 2016 at 05:13:50AM +0100, Guillem Jover wrote:
> > I don't know a suitable forum for this type of question. And please don't
> > refer
> > me to the high-traffic ML debian-user, I won't use that one.
>
> You don't need to subscribe to be able to post. Using one of the
> support ch
f the
support channels before sending to d-devel or filing bugs is always
helpful, because it saves maintainers from having to do the triaging
in case this is a local user problem.
> After upgrading to sid the conffiles don't seem to be installed any longer?
> Examples are bash, passwd,
Hi,
On 29.11.2016 17:58, Svante Signell wrote:
> After upgrading to sid the conffiles don't seem to be installed any longer?
> Examples are bash, passwd, basefiles and libpam-runtime. Especially trhe last
> one cost me a day debugging to find out why logins crashed. What is causin
traffic ML debian-user, I won't use that one.
After upgrading to sid the conffiles don't seem to be installed any longer?
Examples are bash, passwd, basefiles and libpam-runtime. Especially trhe last
one cost me a day debugging to find out why logins crashed. What is causing
this, do
Hi,
I've re-built a version of libirt, which has:
> Package: libvirt-daemon-system
> Replaces: libvirt-bin (<< 1.2.7-4~)
> Conflicts: libvirt-bin (<< 1.2.6-1~)
...
> Package: libvirt-bin
> Depends: libvirt-daemon-system (>= ${binary:Version}),
The old "libvirt-bin" package (0.9.12-5) contained
"
On Mon, Oct 12, 2015 at 06:13:40PM +0200, Vincent Bernat wrote:
> ❦ 12 octobre 2015 17:45 +0200, Jakub Wilk :
> > Another possibility is to refrain from fixing the bug, and let unlucky
> > users clean their systems themselves.
>
> I think that's the best solution. All the more if the faulty pack
On Sun, Oct 11, 2015 at 03:49:31PM +, Mattia Rizzolo wrote:
> On Sun, Oct 11, 2015 at 11:03:09AM +0200, Wouter Verhelst wrote:
> > The only way to hand a file (any file) over to another package is by way of
> > 'Replaces:', *without* the Conflicts: and Provides:.
> >
> > Since this is a single
On 2015-10-12, Jakub Wilk wrote:
> Because of a latent bug in debian/rules, pbuilder_0.217 shipped multiple
> files that belonged to pbuilder-uml, including
> /etc/pbuilder/pbuilder-uml.conf. This is bug #800416, which was promptly
> fixed in pbuilder_0.218. The faulty package was only in unsta
❦ 12 octobre 2015 17:45 +0200, Jakub Wilk :
> I'd suggest to do something very simple instead:
> In pbuilder's postinst, if pbuilder-uml status is not-installed,
> simply rm -f /etc/pbuilder/pbuilder-uml.conf.
If for some reason, a user has put a file with this exact same name
here, it would be
As I understand it, this is what happened:
src:pbuilder builds two binary packages: pbuilder and pbuilder-uml.
pbuilder-uml depends on pbuilder.
pbuilder suggests pbuilder-uml.
pbuilder-uml ships /etc/pbuilder/pbuilder-uml.conf.
pbuilder is of course not supposed to ship the same conffile.
Beca
On Sun, Oct 11, 2015 at 11:03:09AM +0200, Wouter Verhelst wrote:
> The only way to hand a file (any file) over to another package is by way of
> 'Replaces:', *without* the Conflicts: and Provides:.
>
> Since this is a single packaga version, you could put the file in pbuilder-uml
> and have that '
On Sat, Oct 10, 2015 at 04:30:28PM +, Mattia Rizzolo wrote:
> Hi fellows debian-devel@ lurkers!
>
> On Sat, Oct 03, 2015 at 09:03:46PM +, Mattia Rizzolo wrote:
> > On Sat, Oct 03, 2015 at 02:33:09PM +0200, Paul Wise wrote:
> > > The recent upgrade did not deal
Hi fellows debian-devel@ lurkers!
On Sat, Oct 03, 2015 at 09:03:46PM +, Mattia Rizzolo wrote:
> On Sat, Oct 03, 2015 at 02:33:09PM +0200, Paul Wise wrote:
> > The recent upgrade did not deal with obsolete conffiles properly.
> > Please use the dpkg-maintscript-helper supp
On Sun, 26 Oct 2014, Jakub Wilk wrote:
> * Henrique de Moraes Holschuh , 2014-10-26, 10:57:
> >"rmdir >/etc/foo/bar/ >/dev/null 2>&1 || true" is always a safe
> >operation...
>
> Instead of ignoring (and hiding) all errors, it's better use
> --ignore-fail-on-non-empty.
That's a GNU coreutils-ism
* Henrique de Moraes Holschuh , 2014-10-26, 10:57:
"rmdir >/etc/foo/bar/ >/dev/null 2>&1 || true" is always a safe
operation...
Instead of ignoring (and hiding) all errors, it's better use
--ignore-fail-on-non-empty.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.deb
gt; > the appropriate and clean way to get rid of *all* conffiles for a
> > package, including the directory that contains them?
>
> I have never used dpkg-maintscripthelper myself, but the documentation
> suggests that dpkg-maintscripthelper is not able to do that (the
> dir
On Sat, Oct 25, 2014 at 12:42:01PM +0200, Enrico Zini wrote:
> Hello,
>
> I have a bug (#764235) in which after I remove all conffiles in
> /etc/debtags with dpkg-maintscripthelper, the /etc/debtags directory
> itself is left around.
>
> This is what happ
Hello,
I have a bug (#764235) in which after I remove all conffiles in
/etc/debtags with dpkg-maintscripthelper, the /etc/debtags directory
itself is left around.
This is what happens:
# dpkg -i debtags_1.12.2_amd64.deb
(Reading database ... 370467 files and directories currently installed
Andreas Beckmann debian.org> writes:
> distros. List of conffiles can be generated by
> grep ^etc Contents
No.
* While debhelper automatically adds all files in etc/ to conffiles,
this is not a requirement.
* Files not under etc/ may also be conffiles.
* Conffiles are listed in th
Hi,
in order to evaluate the possible impact and the packages affected by
Bug #689836: dpkg: md5sums incorrectly recorded for conffile takeover
http://bugs.debian.org/689836
I'd like to generate lists of md5sums for the conffiles shipped in the
distros. List of conffiles can be generat
>>>>> Thomas Goirand writes:
[…]
> BTW, "conffiles" is a pretty bad name. It's confusing, as you can
> see once more.
> I thought about calling it "dpkg-conffiles" which has the advantage
> of underlying that we leave the handling of
On 2012-09-19 15:25, Adam D. Barratt wrote:
> On 19.09.2012 08:44, Andreas Beckmann wrote:
>> If noone objects, I'll go ahead with filing these bugs with Severity:
>> serious since this is a violation of a "must" directive.
>
> Do we have an idea of how many such bugs there are affecting wheezy
>
On 19.09.2012 08:44, Andreas Beckmann wrote:
If noone objects, I'll go ahead with filing these bugs with Severity:
serious since this is a violation of a "must" directive.
Do we have an idea of how many such bugs there are affecting wheezy
currently? Apologies if that was answered earlier in
Hi Andreas,
thanks for your work on this, again! :-)
On Mittwoch, 19. September 2012, Andreas Beckmann wrote:
> = 8< =
> To: sub...@bugs.debian.org
> Subject: modifies conffiles (policy 10.7.3):
I miss one sentence in this mail template: "Please see the attached
ages in squeeze,
though. Therefore I'm asking the Release Team for permission to tag them
as squeeze-ignore immediately.
= 8< =
To: sub...@bugs.debian.org
Subject: modifies conffiles (policy 10.7.3):
Package:
Version:
Severity: serious
User: debian...@lists.debian.org
Usertags: piupa
On Wed, 08 Feb 2012, Michael Biebl wrote:
> As mentioned, a simple Replaces in the newly split-off package is
> not sufficient, as you will have obsolete conffiles, in case the new
> split-off package is not installed.
> I've seen this problem a couple of times and I th
/bar.conf
(both marked as conffiles)
after the split (done in version 1.0-1):
binary package foo:
/bin/foo
/etc/foo.conf
binary package bar:
/bin/bar
/etc/bar.conf
Package foo in version 1.0-1 does not have a dependency on bar, so bar
is not guaranteed to be installed.
There is also the case, where
Hi,
Am 08.02.2012 08:27, schrieb Raphael Hertzog:
What's difficult in implementing this?
I haven't found cocumentation how to correctly move conffiles from one
package to another. Neither at [1] nor the dpkg-maintscript-helper man page.
As mentioned, a simple Replaces in the newly
62f506fda3305 obsolete
> >>
> >> How can I fix this issue and convert to dependency based boot?
> >
> > Delete the above three files and try again. bootlogd was moved into
> > a separate package recently.
>
> As bootlogd has been split off from sysvinit-uti
506fda3305 obsolete
>>
>> How can I fix this issue and convert to dependency based boot?
>
> Delete the above three files and try again. bootlogd was moved into
> a separate package recently.
As bootlogd has been split off from sysvinit-utils into a separate
package, I'
ed
that seem to have local configuration. At least you could check for modified
conffiles owned by the package and for package-owned directories under /etc that
are nonempty (excluding false positives such as unmodified package-installed
files when possible).
--
To UNSUBSCRIBE, email to d
t; config with new defaults.
> By default, dpkg will silently upgrade unmodified conffiles to the
> current version, without prompting the user at all. If you've modified
> the conffile, dpkg will prompt you to find out if you want to keep your
> modified version, upgrade to the new up
t all. The main problem is, on updates, defaults
> might silently change, without operators used to look at /etc
> and comparing current config with new defaults.
By default, dpkg will silently upgrade unmodified conffiles to the
current version, without prompting the user at all. If you'
* Tanguy Ortolo schrieb:
> I think having the default configuration values written in a default
> configuration file under /usr is better than having them harcoded, since
> it makes it really easier to determine what these defaults are. But not
> shipping the user configuration file, I do not kno
On Fri, Dec 30, 2011 at 02:00:23PM +, Tanguy Ortolo wrote:
> I think having the default configuration values written in a default
> configuration file under /usr is better than having them harcoded, since
> it makes it really easier to determine what these defaults are.
It's problematic if the
Carlos Alberto Lopez Perez, 2011-12-30 14:22+0100:
> I think that stephan is right here. Every package using files in /etc
> should ship this files in the package in order to let the admin know
> what package each file belongs to. Its very ugly to do a "dpkg -S
> /etc/xxx" and get a no path found.
Ian Jackson writes:
> Goswin von Brederlow writes ("Transitional packages with conffiles"):
>> Looking into the cause we discovered that the problem is that
>> dhcp3-client is now a transitional package that pulls in
>> isc-dhcp-client. The new package expect
On Wed, Mar 16, 2011 at 02:01:37PM +, Ian Jackson wrote:
> Well surely the question is: why are the files moved to a different
> directory ? Why is the package renamed, even ? Do we need to be able
> to co-install the old and new ISC DHCP clients ?!
The original dhcp-client was version 2. d
Goswin von Brederlow writes ("Transitional packages with conffiles"):
> Looking into the cause we discovered that the problem is that
> dhcp3-client is now a transitional package that pulls in
> isc-dhcp-client. The new package expects its config files in /etc/dhcp
> while
On a somewhat related note:
If a package is manually installed, then replaced with a transitional
package, then apt should mark the transitional package's dependencies
as manually installed and the transitional package as automatically
installed. Otherwise, when one removes the transitional packa
conffiles.
Wouldn't it be nice to detect when local configuration changes are lost
due to package migration?
Obviously it would be nice if the migration would also migrate the old
config to the new package but that isn't allways possible. In those
cases I think it would be nice to give a
peter green wrote:
>> So, what do you suggest for this? Of course, this file _is_ a conffile
>> (i.e. should never be automatically overwritten, so just moving it
>> over to /var/lib is not just compiling with a different path set). If
>> I don't automatically upgrade the file, users will end up wi
So, what do you suggest for this? Of course, this file _is_ a conffile
(i.e. should never be automatically overwritten, so just moving it
over to /var/lib is not just compiling with a different path set). If
I don't automatically upgrade the file, users will end up with a
confused daemon unable an
Holger Levsen dijo [Wed, Aug 19, 2009 at 12:15:04PM +0200]:
> Hi,
>
> for some packages the piuparts upgrade test failed because dpkg detected a
> conffile as being modified and then prompted the user for an action. As there
> is no user input, this fails. But this is not the real problem, the r
Hi,
On Mittwoch, 19. August 2009, Steve Langasek wrote:
> On Wed, Aug 19, 2009 at 12:15:04PM +0200, Holger Levsen wrote:
> > The logs are linked from
> > http://piuparts.debian.org/squeeze/conffile_prompt_error.html
> Not harmless at all. These are serious bugs.
I'll file those accordingly :-)
On Wed, Aug 19, 2009 at 12:15:04PM +0200, Holger Levsen wrote:
> Affected packages are:
> cdd-dev_0.6.3
> cherokee_0.99.20-1
> conntrackd_1:0.9.12-1
> junior-config_1.15
> med-config_1.2
> openswan_1:2.6.22+dfsg-1.1
> science-config_0.6
> The logs are linked from
> http://piuparts.debian.org/sq
s that this prompt shows up in the first place, as there was nobody
> modifying this conffile at all, the package has just been installed and
> upgraded...
>
> This is a violation of policy 10.7.3, see
> http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3, which
> say
there was nobody
modifying this conffile at all, the package has just been installed and
upgraded...
This is a violation of policy 10.7.3, see
http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3, which
says "[These scripts handling conffiles] must not ask unnecessary ques
of
> /etc/postgresql/8.2/main/pg_hba.conf would be lost at present.
>
> Does the Policy admit this kind of handling of conffiles?
I don't mean to speak for the PostgreSQL package maintainers. But
postgresql-8.2 and postgresql-8.3 are different packages. So unless you
purge the postgr
Does the Policy admit this kind of handling of conffiles?
Regards,2008-5-2(Fri)
--
Debian Developer - much more I18N of Debian
Atsuhito Kohda
Department of Math., Univ. of Tokushima
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubs
On Wed, 2006-12-27 at 12:40 +, Colin Watson wrote:
> But from etch onwards, the job consists of putting the file in a
> different package and adding a Replaces. There'd be nothing for a
> debhelper program to do. Sure, maybe a year ago it would have been worth
> it - but it's now too late to
On Tue, Dec 26, 2006 at 08:08:19PM +1100, Robert Collins wrote:
> On Tue, 2006-12-26 at 02:50 -0600, Manoj Srivastava wrote:
> > How often do you think this shall be needed in this release
> > cycle? Writing a general purpose dh_tool, and getting it tested, is
> > not a simple task (thou
; > be hinted into testing if its five days expire without any new RC bugs;
> > also that all other packages that have had to deal with moving conffiles
> > between packages may be affected by a similar problem depending on
> > whether they're upgraded with sarge's dpk
m sarge
> >> to etch, and once we can expect everyone to have etch's dpkg
> >> installed we can move conffiles between packages more or less like
> >> any other files.
>
> > is it possible/useful to generate a dh_ command to facilitate this?
> > R
g
>> installed we can move conffiles between packages more or less like
>> any other files.
> is it possible/useful to generate a dh_ command to facilitate this?
> Rather than everyone needing to end up encoding the same logic with
> minute variations ?
How often do
at all other packages that have had to deal with moving conffiles
> between packages may be affected by a similar problem depending on
> whether they're upgraded with sarge's dpkg or etch's dpkg, and need to
> be reviewed and corrected before release.]
...
> Fortuna
[debian-release: Read this if you care about the details. The executive
summary is to note that openssh 1:4.3p2-8 corrects an RC bug and should
be hinted into testing if its five days expire without any new RC bugs;
also that all other packages that have had to deal with moving conffiles
between
On Tue, Dec 12, 2006 at 04:17:56PM -0800, Russ Allbery wrote:
> Brian May <[EMAIL PROTECTED]> writes:
> > As far as I can tell from 402806, with a bit of guessing, what happens
> > is:
>
> > 1. unpack latest ssh-krb5
> >(old conffiles not deleted)
> &
Brian May <[EMAIL PROTECTED]> writes:
>>>>>> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:
> Russ> Could someone who knows more about how Conflicts and
> Russ> Replaces is supposed to work, particularly in combination
>
>>>>> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:
Russ> Could someone who knows more about how Conflicts and
Russ> Replaces is supposed to work, particularly in combination
Russ> with conffiles, take a look at bugs #402804 and #402806
Could someone who knows more about how Conflicts and Replaces is supposed
to work, particularly in combination with conffiles, take a look at bugs
#402804 and #402806? I don't understand why this isn't working. It looks
to me like all the right Conflicts and Replaces are in place s
"cobaco (aka Bart Cornelis)" <[EMAIL PROTECTED]> wrote:
> So you can for example have 4 config sets (each in its own location):
> - one with the upstream default values
> - one with overrides for upstream settings by maintainer
> - one with cdd-overrides for the settings
> - one with admin-overrid
> configuration files - in principle, each of them can be changed in
> > order to change the behavior of the system. We are currently thinking
> > about a solution were there would be hardly any conffiles[1], but a
> > local admin could put copies of any file he likes into sub
Hi all,
Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> Frank Küster <[EMAIL PROTECTED]> writes:
>> We are currently thinking about a
>> solution were there would be hardly any conffiles[1], but a local admin
>> could put copies of any file he likes into subd
ange the behavior of the system. We are currently thinking about a
> solution were there would be hardly any conffiles[1], but a local admin
> could put copies of any file he likes into subdirectories of /etc/texmf.
> This would shadow the dpkg-shipped file in /usr/share/texmf and allow
&
der
> to change the behavior of the system. We are currently thinking about a
> solution were there would be hardly any conffiles[1], but a local admin
> could put copies of any file he likes into subdirectories of /etc/texmf.
> This would shadow the dpkg-shipped file in /usr/share/texm
On Nov 21, Frank Küster <[EMAIL PROTECTED]> wrote:
> What do others think? Would it be acceptable Policy-wise to handle
> configuration like this?
Yes.
--
ciao,
Marco
signature.asc
Description: Digital signature
were there would be hardly any conffiles[1], but a local admin
could put copies of any file he likes into subdirectories of /etc/texmf.
This would shadow the dpkg-shipped file in /usr/share/texmf and allow
configuration. And of course we would document this.
There is one major drawback, however: If a
Le samedi 25 juin 2005 à 22:16 +0200, Marc Haber a écrit :
> On Fri, 24 Jun 2005 11:40:54 +0200, Julien Cristau
> <[EMAIL PROTECTED]> wrote:
> >On Fri, Jun 24, 2005 at 11:35:17 +0200, Gerrit Pape wrote:
> >> Hi, what exactly is the problem with diverting c
On Fri, 24 Jun 2005 11:40:54 +0200, Julien Cristau
<[EMAIL PROTECTED]> wrote:
>On Fri, Jun 24, 2005 at 11:35:17 +0200, Gerrit Pape wrote:
>> On Tue, May 31, 2005 at 11:08:27PM +0200, Tollef Fog Heen wrote:
>> > Be aware of the fact that diverting conffiles doesn't wor
On Fri, Jun 24, 2005 at 11:35:17 +0200, Gerrit Pape wrote:
> On Tue, May 31, 2005 at 11:08:27PM +0200, Tollef Fog Heen wrote:
> > Be aware of the fact that diverting conffiles doesn't work.
>
> Hi, what exactly is the problem with diverting conffiles?
>
See http://bugs.de
On Tue, May 31, 2005 at 11:08:27PM +0200, Tollef Fog Heen wrote:
> Be aware of the fact that diverting conffiles doesn't work.
Hi, what exactly is the problem with diverting conffiles?
Thanks, Gerrit.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscr
* Joerg Sommer [Thu, 05 May 2005 20:39:57 +]:
> Hi,
> in an old version of jed-common two conffiles 00site.sl and 99debian.sl
> were included. But caused by some reason they aren't removed on upgrade.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=266981
> Becomes a
Hi,
in an old version of jed-common two conffiles 00site.sl and 99debian.sl
were included. But caused by some reason they aren't removed on upgrade.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=266981
Becomes a conffile held if it was modified when it is removed in a new
package ve
against
> $ man dlocate
> -conf list conffiles in package
> saying to mention in the man page the cases when conffiles might not
> be listed?
conffile != configuration file [1].
Please don't file a bogus bug about this.
--Jeroen
[1] http://www.debian.org/doc/debian-policy/ch-file
>> Shouldn't all the files in /etc/lynx-cur be listed, and as conffiles?
>> $ dlocate /etc/lynx-cur/|wc -l
>> 1
>> $ ls /etc/lynx-cur/|wc -l
>> 21
A> I believe no, they shouldn't be listed.
A> Only /etc/lynx-cur/lynx.cfg is shipped with the packa
When apt-ing more than one package group the conffiles question together
(probably at the end) the way it is done with debconf questions. When doing
apt-get upgrade I want to be able to leave and know that everything what can
be done automatically is done. Now the instalation of the other pac
t;supplied by the package (if any) , while other packages' confiles
>>should be keep the locally modified version.
>>
>>Is this possible?
MP> Not that I know of, but it would be an interesting modification to make to
MP> dpkg (which is the program that m
1 - 100 of 139 matches
Mail list logo
