Feature changed by: Stephen Shaw (decriptor) Feature #310198, revision 4 Title: Allow for non version specific distro specific spec files Buildservice: Unconfirmed Priority Requester: Important Requested by: Stephen Shaw (decriptor) Description: Its nice that you can create a spec file that is specific to a distro and release, ie packages-openSUSE_11.3.spec and packages-Fedora_13. spec, but it would be really nice if I could have something like this:   packages-openSUSE.spec (catch all for all openSUSE based repositories) packages-openSUSE_11.3.spec (this would take precedence over packages- openSUSE.spec) packages-Fedora.spec (catch all for all Fedora based repositories) packages-Fedora_12.spec (this would take precedence over packages- Fedora.spec)   The idea is that a spec file for openSUSE might differ enough from an Fedora spec file and there are 2 openSUSE repositories and 2 Fedora repositories.  By doing this I'd only really need 2 spec files instead of 4. Discussion: #1: Pascal Bleser (pbleser) (2010-07-24 13:25:13) I've yet to see use cases where that would make sense, as you're better off handling the minor differences between e.g. openSUSE versions with conditionals (%if .. %endif). Separate spec files really only make sense when 90% of the spec file differs, because they have the huge drawback of requiring to be kept in sync (same %description, same Summary, same URL, same Copyright, same % build, same %install, almost same %files (but there are macros like % {ext_man} for that), etc...) Personally, I believe that per-distribution spec files are really not compelling as they make up for a lot more work than using conditionals -- even though those conditionals can get ugly at times, no question about that. IMHO, the best approach would actually to have more macros that handle some/most of the differences between the RPM based distributions we have in the OBS in a comfortable way. + #2: Stephen Shaw (decriptor) (2010-07-24 22:31:27) (reply to #1) + I have a case where there is enough difference between the fedora and + openSUSE packages that the spec file would become very messy.  I can + put in %if .. %endif and it'll still be a bit mess and that's just for + one distro, but doable.  I'd be nice to have a fedora package and an + openSUSE package.  I really don't want to have 20 %if .. %endif because + certain versions of the distro provide one of the BuildRequires and the + other doesn't, one distro puts the installed files in a different + location than the other, one has a BuildRequires that have the package + name slightly different, and one doesn't split out the packages the + same way. -- openSUSE Feature: https://features.opensuse.org/310198

Feature changed by: Sascha Peilicke (saschpe) Feature #310198, revision 6 Title: Allow for non version specific distro specific spec files - Buildservice: Unconfirmed + Buildservice: Rejected by Sascha Peilicke (saschpe) + reject reason: See comments Priority Requester: Important Requested by: Stephen Shaw (decriptor) Partner organization: openSUSE.org Description: Its nice that you can create a spec file that is specific to a distro and release, ie packages-openSUSE_11.3.spec and packages-Fedora_13. spec, but it would be really nice if I could have something like this:   packages-openSUSE.spec (catch all for all openSUSE based repositories) packages-openSUSE_11.3.spec (this would take precedence over packages- openSUSE.spec) packages-Fedora.spec (catch all for all Fedora based repositories) packages-Fedora_12.spec (this would take precedence over packages- Fedora.spec)   The idea is that a spec file for openSUSE might differ enough from an Fedora spec file and there are 2 openSUSE repositories and 2 Fedora repositories.  By doing this I'd only really need 2 spec files instead of 4. Discussion: #1: Pascal Bleser (pbleser) (2010-07-24 13:25:13) I've yet to see use cases where that would make sense, as you're better off handling the minor differences between e.g. openSUSE versions with conditionals (%if .. %endif). Separate spec files really only make sense when 90% of the spec file differs, because they have the huge drawback of requiring to be kept in sync (same %description, same Summary, same URL, same Copyright, same % build, same %install, almost same %files (but there are macros like % {ext_man} for that), etc...) Personally, I believe that per-distribution spec files are really not compelling as they make up for a lot more work than using conditionals -- even though those conditionals can get ugly at times, no question about that. IMHO, the best approach would actually to have more macros that handle some/most of the differences between the RPM based distributions we have in the OBS in a comfortable way. #2: Stephen Shaw (decriptor) (2010-07-24 22:31:27) (reply to #1) I have a case where there is enough difference between the fedora and openSUSE packages that the spec file would become very messy.  I can put in %if .. %endif and it'll still be a bit mess and that's just for one distro, but doable.  I'd be nice to have a fedora package and an openSUSE package.  I really don't want to have 20 %if .. %endif because certain versions of the distro provide one of the BuildRequires and the other doesn't, one distro puts the installed files in a different location than the other, one has a BuildRequires that have the package name slightly different, and one doesn't split out the packages the same way. #3: Stephen Shaw (decriptor) (2010-07-24 22:44:57) (reply to #1) Another reason for this too is that I want to upstream my packages to both distros, but don't want a ton of %if .. %endif statements.  Do we want that in all of our openSUSE packages that are released in our distro? + #4: Sascha Peilicke (saschpe) (2011-02-18 11:44:19) (reply to #3) + Fedora is using different specs for different releases, openSUSE + doesn't because it's mostly about changed build dependencies and + doesn't spam the spec really that much. + The effort needed for this feature doesn't seem worth it for me. + However, patches are always appreciated. -- openSUSE Feature: https://features.opensuse.org/310198