Is a tinderbox suitable for a customized local package tree?

[Joe Marcus Clarke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Harding wrote:
> On Wed, 2006-07-12 at 17:26 -0400, Joe Marcus Clarke wrote:
> 
>> Sure, TB would work for this.  It sounds like you already know what you
>> want to do to the tree, so once you have the ports tree to your liking,
>> just follow the rest of the TB documentation for setup.  I do something
>> similar for building GNOME developments ports.
>>
>>> I have already built a tinderbox, I would at the very least need to sync
>>> the package tree -only- after I can verify a build, correct?  Can I just
>>> do a tinderbuild -updateports, or do I need to clear out the packages
>>> occasionally?
>> You shouldn't need to clear out the packages.  Tinderbox handles
>> dependencies, and will track version changes.  You may want to clear
>> things out from time to time if you have a -CURRENT build, though.
>>
>> As for handling the ports tree updates, you can write a script that
>> applies local patches to your tree, and set your update command to point
>> to this script.  For my MarcusCom GNOME devel ports tree, I use the
>> marcuscom.sh script included in the TB distribution.
>>
>> Joe
>>
> 
> Thanks for the excellent feedback, Joe!  Any thoughts on dealing with
> the 'broken tree' problem?  Basically, I want to stop updating the
> package tree presented to internal users if the build breaks, but this
> is difficult, of course, because the build breaks 'upstream' from the
> changed port.
> 
> I'm specifically thinking about the 2.12->2.14 upgrade, where it took a
> while to get thing shaken out.  If somehow, the old stuff still worked,
> that would be great.  If we could trigger a copy of the packages only on
> a good build, that would be almost as good...

This is doable.  If the build fails, you will know about it (either via
email, or because you scripted the call to tinderbuild, and you're
checking the rc).  Upon a successful build, you could then export the
package tree to users via NFS, and if the next build fails, you could
remove the mount (or something like that).

Joe

- --
PGP Key : http://www.marcuscom.com/pgp.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEtXOQb2iPiv4Uz4cRAsUQAJ0SzCNwMgXSS+tGI9yGhmgoX8woSACeNb2j
GuDuhPdiXDdkgzHh7liI7tE=
=Zxa/
-----END PGP SIGNATURE-----