Zbigniew Jędrzejewski-Szmek píše v Po 11. 04. 2016 v 18:30 +0000: > > > > 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. > That of course is nice. But if in the end all distros do something else it is utterly useless. So it still stands as nice example of distros not cooperating.
And if it is in upstream repository then we should kick the distros to merge the changes back of course, so no need to move those. Generaly tho most upstreams do not care about rpm distros. Just comparing: https://build.opensuse.org/package/view_file/Base:System/systemd/macros .systemd.upstream?expand=1 https://build.opensuse.org/package/view_file/Base:System/systemd-rpm-ma cros/macros.systemd?expand=1 Kinda differ, and blame here is on us at openSUSE of course, but things like this happen too much. > > > > > > > > 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. > Nobody said RPM team should maintain them. It would be de-facto neutral ground for all distros to come. Because if you put it to some namespace under Fedora/SUSE/... it is considered distro agnostic and thus others tend to ignore it. Those macros in the end would be maintained as today by the lads from distributions. We already synced them once, but it diverged simply for the reason of not being in one coherent space. It can in reality be anywhere, this is just pretty good namespace, unless you think to put it to some github "home" project is cooler. Tom
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Rpm-ecosystem mailing list [email protected] http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
