Build once, serve many
jkeating at redhat.com
Fri Jun 15 22:10:13 UTC 2007
On Friday 15 June 2007 17:06:38 Axel Thimm wrote:
> some packages are best build for all releases once only like for
> example firmware, game data and other packages that you know will not
> change from release to release.
> Currently such operations are made manually and one needs to find the
> right person to talk to. I think it would be more consistent if koji
> and friends allowed one to tag a package as such. Perhaps koji's
> tagging is alread enought to "hardlink" a package source and
> binary-wise across releases?
> If so, please enlighten me with the mechanism details, if not, please
> consider this an RFE. :)
Tagging is essentially hardlinking. Only one copy of a build exists on the
file system. If you "tag" that build with multiple tags, it'll be considered
when dealing with said tags. There are some rules however about what tags
can be applied. I think there are some things that will stop you from
tagging a build for a tag that was originally done in a buildroot that is not
associated with that tag through inheritance, IE building something in the
dist-epel4 buildroot, then tagging that build with dist-f8, or dist-olpc2.
If there is no inheritance link I don't think it'll allow you to tag.
Also due to inheritance, say you have a package frobits that was built during
dist-f7 development time and is tagged for dist-fc7. dist-f8 has never seen
a build, it inherits that dist-fc7 one. dist-f9 comes along, and it inherits
that build as well. If you have to do an update, you do an update on the
lowest tag first, and the upper tags will inherit that /new/ build as well.
Inheritance stops as soon as a given "tag" is specifically applied to a
build/package. If you build for dist-fc7, then 'tag' it for dist-f8, then do
another build on dist-fc7, dist-f8 won't see the "new" build in dist-fc7,
it'll continue to "see" the specifically dist-f8 tagged build.
It's a little confusing to write up, but once you understand how inheritance
works it begins to make sense.
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/buildsys/attachments/20070615/839b581d/attachment.bin
More information about the buildsys