In product builds that must span multiple
architectures and multiple packaging methods it is
quite common that rpmbuild not control the build
process, and that the build system does not create a
usable .src.rpm.
The question of whether to use rpm's source
abstraction or not is one of requirements, and not
technical. Binding the rpm creation to the build as
per my original suggestion allows for tight
integration with the upstream build. In that case, the
only valid trigger to start packaging is the
conclusion of the upstream build. The requirement is
that any failure of packaging causes the build to
abort. The pattern also improves reliability in terms
of version tracking.
The proposal of using the built binaries as sources
allows for packaging to be done separately. Sometimes
the procedure is to build and perform preliminary
testing before packaging, or sometimes the product is
released on different platforms at different times, so
the rpm packaging is not always built and tested.
Both abstractions are useful for different products,
and I've certainly used them both.
____________________________________________________________________________________Ready for the edge of your seat?
Check out tonight's top picks on Yahoo! TV.
http://tv.yahoo.com/
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
