gem2rpm and upgrades of existing rpms

[Joe Rafaniello]

----- Original Message -----
> On 06/25/2014 10:15 AM, Joe Rafaniello wrote:
> >> Well, what is in the upstream fermig repository and what I am actually
> >> using during migration periods is not always the same. From my point of
> >> view, it is one shot library, which should be ideally used once a year
> >> (or how often the guidelines are updated) and that is it.
> >>
> >> Actually, I see where are you aiming, i.e. the upgrade of gem is good
> >> opportunity to update the .spec, etc. but from tooling POV, it is easier
> >> to do it in two steps, e.g. update everything in Fedora when guidelines
> >> are updated and upgrade to new version when new version is released.
> >>
> >> Vít
> >>
> > Corrected the line 7) below...
> >
> > Thanks, this is great information.
> > I think it's easier to add "update" functionality to gem2rpm by ensuring
> > the template and spec both get updated to latest conventions.
> 
> 
> Would have to agree w/ Vit on this one, it'd be easier to split things
> into multiple separate use cases:
> 
> - generate a new spec from scratch
> 
> - updated a single package version to new specifications
> 
> - updating a single package between versions
> 
> The Unix philosophy is to build and use simple tools that do simple
> things well. We should try and nail each of these down individually
> before trying to abstract all three into a single stage / tool.
> 
> 
> > It's really complicated to try to apply changes from a spec generated with
> > new conventions into a spec using old or no conventions.
> 
> Have you attempted this? Perhaps some code would better illustrate what
> you are going for?
> 
>   -Mo
> 
> _______________________________________________
> ruby-sig mailing list
> ruby-sig at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Thanks Mo, that's really my point. In order to update a gem version programmatically, there are a series of steps that should happen, regardless if it's the same or different tools:

If using the gem2rpm mechanism to generate a new spec file for the new gem version and merge the applicable changes, you have a few prerequisites:
1) update the template to latest conventions
2) update the existing spec to latest conventions
3) gem2pm using the updated template for new gem version to create the new version spec file

Then compare the new version spec to the old version spec and merge any desired changes.

I don't think you can compare two specs unless they're using the same conventions, otherwise there would be lots of noise in the diff.
I think there are some sections of the spec that can't be easily upgraded automatically for new gem versions but there should be some that we can handle.

Does this make sense or am I missing something?

-- 
Joe Rafaniello