On Sat, Jan 20, 2018 at 7:58 AM, Richard Shaw <hobbes1069@xxxxxxxxx> wrote:
> On Sat, Jan 20, 2018 at 5:27 AM, Igor Gnatenko
> <ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote:
>>
>>
>> * File-triggers are not supported by el6/el7 RPM, so every package which
>> has
>> icons should have some number of scriptlets conditionalized by %if
>> 0%{?rhel}
>> && 0%{?rhel} <= 7.
>
>
> Could this be easily fixed by adding macros to EL that would only run when
> appropriate? Staying with your earlier example:
>
> %post
> %{?epel_update_gtk_icon_cache}
>
>
One thing I've literally never understood is why we tell people to
copy-paste scriptlet logic instead of wrapping it in a macro for
people to use... This is how it was done in Mandriva and SUSE for
years before they transitioned to triggers for things.
Heck, we actually did it for %systemd_post for the systemd package,
but that was only because we *started* with a macro. (And if I
remember correctly, the systemd macros are derived partly from the
SUSE %service_* macros from an earlier point in time).
>>
>> * Rich dependencies are not supported by el6/el7 RPM and YUM, so anyone
>> who
>> wants to use them need to have same conditionals.
>
>
> This can get messy when there are a lot of them, most in my experience with
> at least end user apps, you rarely need them so the occasional:
>
> %if 0%{?fedora}
> Recommends: ...
> %else
> Requires: ...
> %endif
>
> does not hurt readability much.
>
> WIth large libraries that are already complicated that's more difficult, but
> in that case major updates are discouraged within a release and all but
> banned in EL so there's not much need or advantage to keeping the specs in
> sync.
>
I wished weak deps had been backported to EL rpm (at least EL7) so
that we could only need conditionals for rich deps. It's not even that
hard of a backport, and the feature existed in SUSE and
Mageia/Mandriva rpm for years (even going back to rpm 4.4!).
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
