[buildd-tools-devel] Bug#512202: [Buildd-tools-devel] Bug#512202: please create/remove /CurrentlyBuilding
Roger Leigh
rleigh at codelibre.net
Sat Nov 7 11:37:38 UTC 2009
clone 512202 -1
tags 512202 + wontfix
block 512202 by -1
reassign -1 man-db
retitle -1 man-db: Please provide means to disable dpkg trigger
severity -1 wishlist
thanks
On Sun, Jan 18, 2009 at 03:14:43PM +0000, Robert Millan wrote:
> The Debian man-db package has the following check in its postinst:
>
> if [ -f /CurrentlyBuilding ]; then
> # Skip building the database when running in a buildd environment,
> # to avoid wasting time. (At the moment, this check only works for
> # Ubuntu's buildds. Furthermore, detectable buildds are a
> # double-edged sword, so maybe this should be replaced with the
> # ability to preseed something to prevent building the database.)
> echo "... skipping, since this is a buildd" >&2
> return 0
> fi
>
> It would be nice if this was useful with Debian buildds. It would save a
> lot of wasted time because of the database being regenerated every time
> debhelper installation drags in man-db.
>
> Please consider creating/removing that file stamp when sbuild is invoked.
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
So to summarise, there are potentially significant gains to disabling
the man-db dpkg trigger in a buildd environment. However, package
maintainer scripts should not need to be aware of the fact they are
running in a buildd environment. It looks like a general dpkg
mechanism is not going to happen, so a man-db-provided mechanism for
disabling its trigger (such as a debconf parameter?) would allow
buildd/sbuild to selectively disable it without the package being
aware of the specific environment.
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.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20091107/63ef90f3/attachment-0001.pgp>
More information about the Buildd-tools-devel
mailing list