On 2/8/2013 10:03, Michael K. Johnson wrote:
On Fri, Feb 08, 2013 at 07:11:27AM -0500, Michael K. Johnson wrote:
This does not mean that all recipes are factories. We can use CI
to check source from Git directly into conary source components
(push) instead of having conary fetch from Git (pull), which might
make packages easier to understand.
I'd like to note that this is what rPath wrote the "bob" tool for;
that's why you see a bunch of recipes inside conary packages. It
is how rPath implemented CI: Jenkins jobs ran bob to go from a
Mercurial checkin to troves built into a repository. Bob (the
builder...) was an implementation of the push model.
This is mildly tangential to the discussion but I'd like to take a
second to explain why I think the "pull" model is heretical, since I
complain about factory-hgsource a great deal but haven't really
attempted to explain why. The core, underlying problem is that it
violates the contract that a recipe must fulfill: that it must not use
anything stored outside of the repository to complete the build once the
source is committed, and consequently that building the same source
twice must produce identical results. It also comes with many practical
issues such as needing extra tools and scratch space just to evaluate
the recipe, which rMake does multiple times in different contexts. A
push model doesn't have any of these issues because once the source is
committed, it's just another Conary source trove and can be evaluated
without any extra code, disk or network resources, even if the source
control goes offline. I wholeheartedly endorse a model where recipes are
committed to, and automatically built from, Git. But the right way to
make that happen is to push the recipe from an outside tool, not a factory.
Disclaimer: I wrote bob, it is my ugly baby. But I'm not necessarily
endorsing bob specifically. It's best to design a system of metadata
that makes sense first and write or adapt the tool later.
-- m. tharp
_______________________________________________
Foresight-devel mailing list
[email protected]
https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
