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

[Florian Festi]

On 04/11/2016 08:30 PM, Zbigniew Jędrzejewski-Szmek wrote:
>> 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

Yes. This is about what I had in mind when suggesting a shared repo.
There is no point in making this a real "package" with release cycles
and everything that comes with it. Think more of it like an wiki where
people can share patches and ideas and pull out the exact version of the
file they need for one particular packager in their distro - may be even
applying some more patches on top.

> 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.

I fully agree with you here. The idea is not to get "those macros under
the maintenance of the rpm team". We - as rpm upstream - can't and don't
want to take over the work that the distros need to do. This is about
offering a shared and neutral place where people from different distros
can meet, easily have a look what everyone else is doing and talk about
where they can share the same macros - and where not.

So my idea is to have a repository where like two, three dozen people
may have either commit access or have people closely at hand that can
merge in their changes. So the content is actually maintained by people
from the different distros that do have the domain knowledge of all
those languages or package types.

I think this is acceptable security wise as people are supposed to have
an eye on the files they care about and not blindly pull them out of the
repo.

Florian

-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

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

[Neal Gompa]

On Mon, Apr 11, 2016 at 2:30 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> 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.
>

I think the assumption here is that you could use it as a base to
start from, and that regular merging would occur.

For example, Fedora and SUSE both have GitHub organizations. The RPM
organization repository containing these macros could be forked by
both organizations. From there, each distribution would apply their
own changes to suit their needs. In addition, they can push changes
back upstream through a pull request and regularly resync with master.
This makes it much easier to keep compatibility closer together.

This mechanism would make it easy for existing distributions and new
distributions to be able to properly source what they need to support
a wide variety of software as RPM packages.

It would also keep us from sacrificing speed for compatibility, as the
distributions would be regularly forking and merging for their own
distributions.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

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

[Tomas Chvatal]

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.  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

Then the downstreams could just refetch the sources to get the newer
macros as needed.

I don't think we could sell the idea that all macros live in one huge
package or if they are split, most people would complain and expect
them to be delivered either with main package or with -devel package.

Tom

signature.asc
Description: This is a digitally signed message part
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

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

[Zbigniew Jędrzejewski-Szmek]

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.
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem