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
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 w
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
> install
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
* Evgeni Golov [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 usecase" (who
5 matches
Mail list logo
