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

[Roger Leigh]

On Sat, Nov 07, 2009 at 02:53:47PM +0000, Colin Watson wrote:
> 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.

Well, we obviously want to prevent the waste of machine resources.
However, the solution as currently implemented in man-db is not
considered an acceptable solution due to the fact that it requires
man-db to have hard-coded hacks to identify if it's running inside
a buildd environment.

The presence of a special file in the filesystem root is not a
clean solution, at least that's the consensus at the moment.

> 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? :-)

There may be better methods out there (you might well have some better
ideas, these are just suggestions), but some automatable method of
customising man-db's trigger behaviour such as a debconf variable we
can tweak or a file in /etc we can update (/etc/default/man-db?) would
both be viable solutions.  If it's something we can safely check for
and alter if available then we can introduce support for this into
sbuild.

> > 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.

What is being requested is a means of disabling the man-db dpkg
trigger.  This would both allow sbuild/buildd to use this mechanism to
disable the trigger, while at the same time not requiring man-db to
implement buildd-specific hacks--the same facility would also be
usable by the sysadmin or other tools.  AFAICS the main concern with
the current solution is that it's totally buildd-specific, and is
depending upon specific behaviour from sbuild rather than just being
configured to work in a particular way.


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/2c046fbc/attachment.pgp>