On Fri, Sep 14, 2012 at 11:30 AM, Henrique Junior <[log in to unmask]> 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.)