[Rpm-ecosystem] RFC: Better handling of per distro RPM macros

Vít Ondruch vondruch at redhat.com
Fri Mar 4 12:02:52 UTC 2016


I would prefer if the language specific macros are not part of RPM at
all. For Ruby on Fedora, we keep them part of Ruby package and it works
just fine. Not sure why it should not be case for other languages (and I
hope that for example Fedora's Perl guys are working toward this goal).


Vít



Dne 4.3.2016 v 12:18 Florian Festi napsal(a):
> Hi!
>
> Looking at the pull requests #37 and #38 [1] for a while I came to the
> conclusion that RPM macros are quite a mess. But I could not really come
> up with a way to get things cleaned up without breaking existing packages.
>
> In general it is clear that distros and possibly even single packages
> within distros need control over some RPM macros. The speed of rpm
> upstream is just not suited to make quick changes and trying out new
> things. Also changes to packaging need to be in sync with the distros
> live cycle and updating to a new rpm release should not change how
> packages get build.
>
> That's the reason Fedora (as an example) has most of its macros in a
> separate package: redhat-rpm-config. I wonder if it made sense to have
> an shared git repository where distros (or development packages within
> those distros) can share their macro files. Probably with some shared
> files on the top level and with per vendor/distro/may be even distro
> release sub directories.
>
> For one the would make it much easier to see what other distributions do
> or how they solve specific problems. Also it would allow global changes
> while keeping the per vendor versions unaffected by pushing the old
> behavior down into the vendor files.
>
> Is this something people are interested in? What
> layout/features/policies should such a repository have? Does it need
> special things like sections for languages like Perl, Python, ... or
> features like language sub packages, debuginfo packages, ... ?
>
> Florian
>
> [1] https://github.com/rpm-software-management/rpm/pull/37
>     https://github.com/rpm-software-management/rpm/pull/38



More information about the Rpm-ecosystem mailing list