On Mon, May 31, 2010 at 09:02:50PM -0700, Steve Langasek wrote:
Hmm, what's the risk of changing it? I guess if dependencies are allowed to
be purged when a package depending on them is removed-but-not-purged,
dbconfig-common could obliterate config files that the depending package
expects to
Hi Evgeni,
On Thu, May 27, 2010 at 11:32:06AM +0200, Evgeni Golov wrote:
This means that we *try* to execute the postrm-hook of dbconfig-common
in our postrm, but only if it's there. Policy 7.2 says The Depends
field should also be used if the postinst, prerm or postrm scripts
require the
hi,
On Mon, May 31, 2010 at 12:24:48PM -0700, Steve Langasek wrote:
Does dbconfig-common know about all of these config files?
I think it's the responsibility of dbconfig-common to track them, and remove
them on purge. That way if your package is purged while dbconfig-common is
installed,
On Tue, Jun 01, 2010 at 01:13:28AM +0200, sean finney wrote:
On Mon, May 31, 2010 at 12:24:48PM -0700, Steve Langasek wrote:
Does dbconfig-common know about all of these config files?
I think it's the responsibility of dbconfig-common to track them, and remove
them on purge. That way if
Hi,
piuparts has discovered a problem with one of my packages [1] and while
analyzing it, Holger and I came to the result, that piuparts *may* be
working wrong here - it removes the depends before purging my
(the tested) package.
Thus we are seeking for your opinion and suggestions.
For those
* Evgeni Golov evg...@debian.org [100527 11:32]:
Alternatively, we could modify piuparts not to remove dbconfig-common
before the tested package isn't gone (or actually: not to try to remove
any deps before the tested package isn't gone) and thus ignore this
problem, defining it as not usual
6 matches
Mail list logo
