On Mon, Apr 11, 2016 at 05:18:29PM +0200, Tomas Chvatal wrote: > Orion Poplawski píše v Po 11. 04. 2016 v 09:11 -0600: > > On 04/11/2016 07:46 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > > > > 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 > > > > > But the problem is that they generally live in the downstream distro > > packages > > as most upstreams don't particularly care about rpm > > packaging. systemd was explicitly given as one of the examples. Upstream systemd certainly cares about rpm packaging, we actually contributed patches to rpm to support our needs, and I don't think anything would be gained by moving the macros elsewhere.
> > Although I > > agree that from a distro point of view splitting the macros out to > > the > > packages is the most appropriate. > > > > I'm not sure we need any particularly formal release process for this > > so I > > think something like: > > > > rpm-macros/python/ > > /perl/ > > /.../ > > > > And then the distro package just update their copies as needed. > > > > Or perhaps the python-rpm-macros could serve as a template for cross- > > distro > > domain specific macros packages. > > > I would shoot for idea where the bla.macros would just sit in git and > the packages would specify as sources the macros ie.: > Source99: https://github.com/rpm/rpm-macros/archive/python.macros This moves those macros under the maintenance of the rpm team. I guess this could work for a few projects, let's say perl and python, but I don't see how this can scale (to perl, python, java, js, lisp, mono, swift, node, ocaml, octave, php, R, ruby, tcl, etc, etc, etc). RPM should instead provide a featureful base upon which individual projects can build. Zbyszek _______________________________________________ Rpm-ecosystem mailing list [email protected] http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
