[Rpm-ecosystem] Sync of rpm macros between Fedora/openSUSE

Zbigniew Jędrzejewski-Szmek zbyszek at in.waw.pl
Mon Apr 11 13:46:26 UTC 2016


Hi,

On Fri, Apr 01, 2016 at 01:45:15PM +0200, Tomas Chvatal wrote:
> Atm most of the macros are stored together with the packages they are
> used for (kde macros in kde, systemd in systemd, python in python, etc
> etc).

...and that sounds just right. Macros should evolve along with their
projects. Moving them to rpm or some central repository just
needlessly ties their lifecycle to something external and makes it
harder for people who are specialists in a given area to evolve the
macros.

And moving things out of their upstream projects moves things away
from your stated goal: after all the distributions share the same upstreams,
so if the projects' macros are used, they are identical in all distributions.
At least for systemd keeping the macros upstream and simply including
them in systemd.rpm works nicely. This model might not work for some
upstream projects like Python because of their long release cycle.
In those cases there could be a sub-project just for the macros, living
a life of it's own, possible shared between distributions. Would
http://pkgs.fedoraproject.org/cgit/rpms/python-rpm-macros.git/
be useful for SUSE?

Zbyszek

> I would suggest we create some common repository to contain these
> and slowly merge them in. After all the packages can then download
> files from this repository quite fine and we can still keep the
> modularity of not having to put all the macros to rpm or to have some
> package like rpm-macros-blob containing everything.
> 
> Because as we did this already once in past it worked for a bit but
> then we started to diverge a lot again. With common repository we could
> accomodate for most needs and actually make it work.
> 
> Ie. we at SUSE have multiple ruby implementations so we have overbroad
> macros for that, but there is no reason why those macros could not
> understand RH system and use simplified values for that and vice-versa
> in other scenarios.


More information about the Rpm-ecosystem mailing list