Hi! On Tue, 2014-09-02 at 10:10:18 +0200, Petter Reinholdtsen wrote: > Following up on a old bug, which now affect packages related to apache2. > > The new apache2 postinst code need such mechanism too. I ran into this > when migrating sitesummary to the new apache2 setup. The sitesummary > package recommends apache2, and when apache2 is configured before > sitesummary, the sitesummary server is set up automatically. But as it > is only a recommends, the ordering is not guaranteed and if apache2 is > unpacked before sitesummary but configured after it, the sitesummary > postinst fail. This is bug <URL: https://bugs.debian.org/760084 >. A > similar bug is <URL: https://bugs.debian.org/745834 > regarding the svn > webdav setup.
I've not checked those bug reports, but I'm assuming that the package might also fail in case apache2 is not installed at all? Or how do you handle that case? And the subsequent missing configuration when apache2 gets installed later on? > What about making sure dpkg take recommends into account when ordering > postinst scripts? If package A recommends B, and both A and B is > installed in the same dpkg run, the postinst scripts should run in order > B.postinst, A.postinst. It would solve the problem I see, and allow for > a mechanism to specify postinst ordering also for non-depend > relationships. I don't think this is a good idea, and I should review the old discussion in this bug, but my gut feeling is that there's not much there, and this should simply be tagged wontfix and closed. Will be doing that this week. The problem is that it would make the dependency resolution harder, as that's in fact changing the Recommends to Depends. So dpkg would have less leeway when there are dependency cycles and similar. But see below. > Is there a better way to fix the problems we experience in bugs #760084 > and #745834? I think using triggers would solve all your problems. It would also cover the case where a user installs sitesummary, but not apache2, and later on installs apache2. You might need to coordinate with the apache2 team to create possibly an explicit trigger name for this. Or would that not solve your problem? Thanks, Guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
