On Fri, Sep 14, 2012 at 11:30 AM, Henrique Junior <henrique...@gmail.com> wrote: > Here is the answer from the team: > "The fedora build setup has git branches for each release EL-5, EL-6, F17, > F19, Master, so there is no problem to have different .SPEC files for each > branch" and > "And is perfectly fine to have conditionals as well:"
Unfortunately, there are literally dozens of ways to do the conditionals, and many of htem are *very* bad. There are some good ones I invested a lot work to set conditionals correctly for the Subversion RPM's at Repoforge, and it involved a lot of cleanup work. The public Samba RPM's at samba.org are nasty, they try to conditionally process the available /etc/redhat-release, /etc/suse-release, etc. It's theoretically possible to process /etc/issue.net, which is always present, but you wind up filling pages with conditionals to handle the weird OS's that decided to alter the layout: "Red Hat's" decision for "Red Hat" to be two words, Oracle's decision to leave the release name out of the data in /etc/issue.net, all combine to create adventures. RPM macros settings, such as "el4", "el6", etc. are useful but inconsistently enabled in RPM configurations. It's..... going to be awkward to write SRPM's that can be simply rebuilt on both Scientific Linux and updated Fedora releases. It's awkward enough that the formats changed between our favorite upstream vendor's versions of RPM for release 5 and release 6. You can get around that using "rpm2xpio file.src.rpm | cpio -id" to extract things. But this is going to make maintaining a single source code line, and keeping it tested for both old and new init setup behavior, very awward. It could have been worse. They could have switched to using daemontools. (B-r-r-r-r-!! I've done RPM's for that for various people, and it''s a *nasty* init toolkit.)
