Re: The value of unmodified conffiles left on disk of removed, but not purged, packages

On 25 February 2018 at 22:42, Don Armstrong <d...@debian.org> 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 ava

Re: The value of unmodified conffiles left on disk of removed, but not purged, packages

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

Re: The value of unmodified conffiles left on disk of removed, but not purged, packages

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.

Re: The value of unmodified conffiles left on disk of removed, but not purged, packages

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

Re: The value of unmodified conffiles left on disk of removed, but not purged, packages

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

The value of unmodified conffiles left on disk of removed, but not purged, packages

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 on d

Re: Installing missing conffiles (was Re: dpkg no longer installs conffiles??)

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 missing AND the conffile changes > > in the new package relative to the one installed (

Re: dpkg no longer installs conffiles??

On Wed, 30 Nov 2016 13:20:43 +0100, Simon Richter <s...@debian.org> 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 > >

Re: Installing missing conffiles (was Re: dpkg no longer installs conffiles??)

gt; missing 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 ext

Re: Installing missing conffiles (was Re: dpkg no longer installs conffiles??)

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 ext

Installing missing conffiles (was Re: dpkg no longer installs conffiles??)

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

Re: dpkg no longer installs conffiles??

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, that

Re: dpkg no longer installs conffiles??

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

Re: dpkg no longer installs conffiles??

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

Re: dpkg no longer installs conffiles??

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:

Re: dpkg no longer installs conffiles??

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 make res

Re: dpkg no longer installs conffiles??

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 disc

Re: dpkg no longer installs conffiles??

en. > >A problem with essential 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 idea

Re: dpkg no longer installs conffiles??

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: >

Re: dpkg no longer installs conffiles??

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 the la

Re: dpkg no longer installs conffiles??

Re: dpkg no longer installs conffiles??

Re: dpkg no longer installs conffiles??

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

Re: dpkg no longer installs conffiles??

ls 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, basefiles and libpam-runt

Re: dpkg no longer installs conffiles??

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 causing >

dpkg no longer installs conffiles??

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 I have some settings

RFH: Breaks (<< $version) for moving conffiles vs. dpkg updating package version too early?

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

Re: Bug#800769: pbuilder: conffiles not removed

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

Re: Bug#800769: pbuilder: conffiles not removed

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

Re: Bug#800769: pbuilder: conffiles not removed

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.

Re: Bug#800769: pbuilder: conffiles not removed

❦ 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

Re: Bug#800769: pbuilder: conffiles not removed

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

Re: Bug#800769: pbuilder: conffiles not removed

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

Re: Bug#800769: pbuilder: conffiles not removed

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

Re: Bug#800769: pbuilder: conffiles not removed

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 s

Re: Removing conffiles AND directories in /etc

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 happens: # dpkg -i debtags_1.12.2_amd64.deb

Re: Removing conffiles AND directories in /etc

* 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 directory part) yet: Current implementation: in the preinst, it checks

Re: Removing conffiles AND directories in /etc

* Henrique de Moraes Holschuh h...@debian.org, 2014-10-26, 10:57: rmdir /etc/foo/bar/ /dev/null 21 || 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

Re: Removing conffiles AND directories in /etc

On Sun, 26 Oct 2014, Jakub Wilk wrote: * Henrique de Moraes Holschuh h...@debian.org, 2014-10-26, 10:57: rmdir /etc/foo/bar/ /dev/null 21 || 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

Removing conffiles AND directories in /etc

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

Re: md5sums for conffiles shipped in the distros

Andreas Beckmann anbe at 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

md5sums for conffiles shipped in the distros

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 generated

conffiles

Thomas Goirand z...@debian.org 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 the file to the responsibility of dpkg, keeps

mass bug filing about packages manipulating conffiles (policy 10.7.3) (was: Re: mass bug filing about packages manipulating/deleting shipped files)

, 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: piuparts Hi, during a test

Re: mass bug filing about packages manipulating conffiles (policy 10.7.3) (was: Re: mass bug filing about packages manipulating/deleting shipped files)

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 log for details

Re: mass bug filing about packages manipulating conffiles (policy 10.7.3) (was: Re: mass bug filing about packages manipulating/deleting shipped files)

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

Re: mass bug filing about packages manipulating conffiles (policy 10.7.3)

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

Re: Taking over conffiles from other packages while cleaning up properly [Re: Problems detected: package initscripts left obsolete init.d script behind]

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 thought it would be worthwile

Re: Taking over conffiles from other packages while cleaning up properly [Re: Problems detected: package initscripts left obsolete init.d script behind]

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 split-off

Re: Taking over conffiles from other packages while cleaning up properly [Re: Problems detected: package initscripts left obsolete init.d script behind]

/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

Taking over conffiles from other packages while cleaning up properly [Re: Problems detected: package initscripts left obsolete init.d script behind]

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'm wondering if there is a way how bootlogd can take over the conffiles while at the same time sysvinit-utils can safely clean up the conffiles in case

Re: Taking over conffiles from other packages while cleaning up properly [Re: Problems detected: package initscripts left obsolete init.d script behind]

? 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'm wondering if there is a way how bootlogd can take over the conffiles For this part, there's nothing to do AFAIK

Re: Conffiles

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 debian-devel-requ...@lists.debian.org with a subject of unsubscribe

Conffiles (was: from / to /usr/: a summary)

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. Not

Re: Conffiles (was: from / to /usr/: a summary)

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

Re: Conffiles (was: from / to /usr/: a summary)

* Tanguy Ortolo tanguy+deb...@ortolo.eu 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

Re: Conffiles (was: from / to /usr/: a summary)

, 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've modified the conffile, dpkg will prompt you

Re: Conffiles

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 upstream version, see a diff, or run

Re: Transitional packages with conffiles

Ian Jackson ijack...@chiark.greenend.org.uk 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 expects its config

Re: Transitional packages with conffiles

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 the old had /etc/dhcp3

Re: Transitional packages with conffiles

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.

Transitional packages with conffiles

with 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 warning

Re: Transitional packages with conffiles

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

Re: piuparts-MBF: prompting due to modified conffiles which where not modified by the user

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 with a

Re: piuparts-MBF: prompting due to modified conffiles which where not modified by the user

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

piuparts-MBF: prompting due to modified conffiles which where not modified by the user

, 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 says [These scripts handling conffiles] must not ask unnecessary questions

Re: piuparts-MBF: prompting due to modified conffiles which where not modified by the user

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 says [These scripts handling conffiles] must not ask

Re: piuparts-MBF: prompting due to modified conffiles which where not modified by the user

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

Re: piuparts-MBF: prompting due to modified conffiles which where not modified by the user

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 :-)

Re: piuparts-MBF: prompting due to modified conffiles which where not modified by the user

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 real

Re: conffiles handling between version up

/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 postgresql-8.2 package nothing should be lost. You

conffiles handling between version up

the Policy admit this kind of handling of conffiles? Regards,2008-5-2(Fri) -- Debian Developer - much more I18N of Debian Atsuhito Kohda kohda AT debian.org Department of Math., Univ. of Tokushima -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject

Re: Duda sobre los conffiles

El lun, 17-03-2008 a las 23:27 +0100, Francisco García escribió: Buenas, A mi me ocurrió algo parecido con un paquete. Puedes probar a quitarlo de conffiles y gestionarlo desde debian/rules, desde el bloque install instalas los ficheros de configuración a su sitio en /etc/... Me

Re: Duda sobre los conffiles

A Dimarts 18 Març 2008, Francisco M. García Claramonte va escriure: El lun, 17-03-2008 a las 23:27 +0100, Francisco García escribió: Buenas, A mi me ocurrió algo parecido con un paquete. Puedes probar a quitarlo de conffiles y gestionarlo desde debian/rules, desde el bloque install

Re: Duda sobre los conffiles

El mar, 18-03-2008 a las 11:08 +0100, Leopold Palomo-Avellaneda escribió: A Dimarts 18 Març 2008, Francisco M. García Claramonte va escriure: El lun, 17-03-2008 a las 23:27 +0100, Francisco García escribió: Puedes probar a quitarlo de conffiles y gestionarlo desde debian/rules, desde el

Re: Duda sobre los conffiles

de conffiles y gestionarlo desde debian/rules, desde el bloque install instalas los ficheros de configuración a su sitio en /etc/... Me refiero, claro está, a directorio_actual/debian/paquete/etc/ Yo lo que tengo es: directorio_actual/debian/paquete1.install

Re: Duda sobre los conffiles

Buenas, A mi me ocurrió algo parecido con un paquete. Puedes probar a quitarlo de conffiles y gestionarlo desde debian/rules, desde el bloque install instalas los ficheros de configuración a su sitio en /etc/... Debería desaparecer el error de lintian. Lo que ocurrirá (puedes probarlo) es que

Duda sobre los conffiles

ficheros .conf que quisiera que el dpkg le preguntara a quien los instale si quiere utilizar la versión del mantenedor o mantener la suya. En la documentación que he leído pone que estos ficheros que quieres tomar en cuenta los pones en un fichero .conffiles. Me encuentro que si pongo en dicho

Re: Moving conffiles between packages, redux

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

Re: Moving conffiles between packages, redux

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 (though of

Re: Moving conffiles between packages, redux

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.] ... Fortunately, all of this is only necessary for upgrades from

Re: Moving conffiles between packages, redux

On Tue, 26 Dec 2006 19:23:40 +1100, Robert Collins [EMAIL PROTECTED] said: On Sat, 2006-12-23 at 23:04 +, Colin Watson wrote: Fortunately, all of this is only necessary for upgrades from sarge to etch, and once we can expect everyone to have etch's dpkg installed we can move conffiles

Re: Moving conffiles between packages, redux

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? Rather than everyone needing to end up encoding the same logic with minute variations ? How

Re: Moving conffiles between packages, redux

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 dpkg or etch's dpkg, and need to be reviewed and corrected before

Moving conffiles between packages, redux

[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

ssh-krb5 Conflicts/Replaces behaving oddly with conffiles

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 so

Re: ssh-krb5 Conflicts/Replaces behaving oddly with conffiles

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? I Russ don't understand why this isn't working

Re: ssh-krb5 Conflicts/Replaces behaving oddly with conffiles

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 with conffiles, take a look at bugs #402804 and #402806? I Russ

Re: ssh-krb5 Conflicts/Replaces behaving oddly with conffiles

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) 2. unpack openssh-server (conflicts is now satisfied

Re: Conffiles and possible conffiles

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-overrides for

Re: Conffiles and possible conffiles

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 subdirectories of /etc/texmf. This would shadow the dpkg-shipped file

Conffiles and possible conffiles

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

Re: Conffiles and possible conffiles

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

Re: Conffiles and possible conffiles

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 configuration

Re: Conffiles and possible conffiles

. 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 configuration. And of course we would document

Re: Conffiles and possible conffiles

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 subdirectories of /etc/texmf. This would shadow

Re: diverting conffiles

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 conffiles? See http://bugs.debian.org/58735

Re: diverting conffiles

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 work. Hi, what exactly is the problem

diverting conffiles

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 unsubscribe. Trouble? Contact

Re: diverting conffiles

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.debian.org/58735. Cheers

  1   2   >