gem2rpm and upgrades of existing rpms

Joe Rafaniello jrafanie at redhat.com
Wed Jun 25 14:04:09 UTC 2014



----- Original Message -----
> Dne 24.6.2014 20:47, Joe Rafaniello napsal(a):
> >
> > ----- Original Message -----
> >> On 06/23/2014 09:58 PM, Joe Rafaniello wrote:
> >>>
> >>> If gem2rpm could handle both initial and updates to the spec, we can
> >>> cleanly separate the responsibilities and just delegate to gem2rpm for
> >>> all
> >>> or some of that work.
> >>> I would be happy to have polisher be the wrapper around gem2rpm for
> >>> larger
> >>> "workflows."
> >>>
> >>> I have only glanced at the gem2rpm code and don't know how much effort it
> >>> is to handle "updates", this is just a curiosity at this point.
> >>>
> >>> For example, I'm curious how are changes in packaging conventions
> >>> currently
> >>> handled?
> >>> Through new gem2rpm templates?
> >> Yes. By default is uses this template[0] which was recently updated to
> >> reflect new ruby 2.1 changes.
> >>
> >>> Is there a migration path for updating an existing rpm spec from an old
> >>> template to a new template?
> >>> Is this all done manually currently?  Are there tools to enforce/verify
> >>> packaging conventions?
> >> Vit, has written a set of scripts which update the specs to current
> >> guidelines[1], I don't know if some edge cases are missed though. You
> >> can follow a previous discussion[2].
> >>
> >> And to chime in the discussion, changing only the sections you mentioned
> >> should not be that big a deal.
> >>
> >> - version is easy to be fetched from rubygems.org
> >> - Changelog is also easy
> >> - Requires are not needed for fc21 and above (could use a different
> >> template for other branches)
> >> - BR could be tricky, since current implementation [3] (correct me if
> >> I'm wring) checks development deps from gemspec and eg. tools needed for
> >> the test suites might not be in that list. So, you can't avoid manual
> >> intervention after all.
> >>
> >> As Josef wrote, ideally what we need is some sort of a web app that
> >> checks/builds every time a new version is out.
> >>
> >>
> >> [0]
> >> https://github.com/lutter/gem2rpm/blob/master/templates/fedora-21-rawhide.spec.erb
> >> [1] https://github.com/voxik/fermig
> >> [2]
> >> https://lists.fedoraproject.org/pipermail/ruby-sig/2014-April/001537.html
> >> [3]
> >> https://github.com/lutter/gem2rpm/blob/master/templates/fedora-21-rawhide.spec.erb#L21
> >>
> >> --
> >> FAS : axilleas
> >> GPG : 0xABF99BE5
> >> Blog: http://axilleas.me
> >> _______________________________________________
> >> ruby-sig mailing list
> >> ruby-sig at lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
> > Thanks.  Those are all good references.
> > Does anyone have opinions as to where automation of spec updates belong?
> > I'm wondering why gem2rpm wasn't used for Vit's "fermig" scripts?
> 
> 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
> 

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.
It's really complicated to try to apply changes from a spec generated with new conventions into a spec using old or no conventions.

1) Update or at least highlight changes needed to the template we're using to abide by conventions
2) Manually or script update the existing template to latest conventions in 1)
3) Commit the updated template
4) Call the fermig scripts to update the existing .spec to latest conventions
5) Commit the .spec with latest conventions
6) Use gem2rpm to generate a new .spec from the updated template in 2) for the desired gem version
7) Apply the applicable changes from 4) into 3) (requires, buildrequires, version, etc.)
8) Take a breathe and see if we broke things ;-)

Do you have any links to distgit repos where the template and spec were upgraded for conventions?
Vit, the scripts don't appear to be cumulative.  So for example, I'd imagine the f19.rb should be run before running update.rb which calls f21.rb.
Is this correct?

> 
> > It would be nice to have one tool that automated some of the rpm spec
> > changes for rubygems packages.
> > I hope to get some cycles to work on adding update to an existing spec in
> > gem2rpm in the next week or so, I'll report back anything I come up with.
> >
> > Thanks.
> >
> 
> _______________________________________________
> ruby-sig mailing list
> ruby-sig at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

-- 
Joe Rafaniello


More information about the ruby-sig mailing list