[buildd-tools-devel] Bug#512202: [Buildd-tools-devel] Bug#512202: please create/remove /CurrentlyBuilding

[Colin Watson]

On Sat, Nov 07, 2009 at 11:37:38AM +0000, Roger Leigh wrote:
> Discussion about this came to the conclusion that we don't want to have
> hacks in packages to let them know they are running in a buildd
> environment.  Abridged IRC log:
> 
> 23:38 < rleigh_> Does anyone have any thoughts about #512202: having a means for
>                  packages to detect if they are being installed in a buildd
>                  environment, or if this is a totally stupid idea?
> 23:47 < Q_> rleigh_: A grep in the logs files shows that man-db is mentioned in about
>             80% of the log files.
> 23:49 < Q_> So for some arches this might be useful.  But I have no idea how much time
>             it ussually takes.
> 23:49 < sgran> probably a more generic way to disable a given trigger would be more
>                useful than touching random files, but that becomes dpkg's issue
> 23:50 < sgran> (I'm thinking of an analogue to invoke-rc.d, so maintainer scripts don't
>                have to know or care that they're in a build root)
> 23:53 < rleigh_> sgran: that would be a better solution.  The suggested
>                  /CurrentlyBuilding that Ubuntu use just looks like an ugly hack IMO.
> 23:53 < Q_> policy-rc.d you mean? :)
> 23:54 < sgran> Q_: well yes, indirectly.  I meant that maintainer scripts only need to
>                call invoke-rc.d and it will do the right thing in the presence of a
>                policy
> 23:54 < Q_> Well, whatever, the first one uses the second to implement the behaviour.
> 23:54 < sgran> the same should happen for triggers
> 0:03 < rleigh_> I'll not introduce the suggestion in #512202 for now then.  A bug
>                  against dpkg for the trigger policy would be great if one isn't
>                  already filed.
> 08:08 < buxy> IMO trigger policy would be overengineering, it should rather be the
>               package implementing the trigger that has to be skipped that could offer
>               it

In summary: buildd admins think dpkg should provide it, dpkg developers
think package maintainers should provide it (which man-db does), buildd
admins won't take advantage of what the package already provides, so
we'll just carry on wasting lots of machine resources.

I no longer have a reliable idea of what Debian buildd admins are going
to consider acceptable. When you guys make up your mind, let me know
what I'm supposed to do, OK? :-)

> I'm tagging the orignal bug wontfix because the fix as requested won't
> be implemented.  However, should man-db ever provide a mechanism to
> disable triggers, we will adopt it.

You mean "should it ever provide a mechanism other than the one it
currently provides"? I'm not sure how I can reasonably hope to deal with
this as a bug on man-db without more information.

Cheers,

-- 
Colin Watson                                       [cjwatson at debian.org]