gem2rpm and upgrades of existing rpms

Joe Rafaniello jrafanie at redhat.com
Mon Jun 23 18:58:51 UTC 2014



----- Original Message -----
> On 06/23/2014 02:01 PM, Joe Rafaniello wrote:
> > ----- Original Message -----
> >> On 06/23/2014 11:20 AM, Joe Rafaniello wrote:
> >>> Hi all,
> >>>
> >>> Does anyone use gem2rpm to upgrade an existing rpm to new versions of
> >>> upstream gems?
> >>>
> >>> I'm contemplating working on a pull request to make gem2rpm aware of an
> >>> existing .spec file and only update specific sections such as: version,
> >>> requires, buildrequires, and adding a changelog.  As it is now, it
> >>> overwrites the existing rpm spec, removing any changelog entries, etc.
> >>>
> >>> Is this a good idea?  What do others do to regenerate the updated
> >>> version,
> >>> requires/buildrequires to avoid human error?
> >>>
> >>> Thanks,
> >>>
> >> You should be able to use polisher from where-ever to do this
> >> programmatically.
> >>
> >> Just updated the last outstanding PR to incorporate your latest feedback
> >>
> >> https://github.com/ManageIQ/polisher/pull/98
> >>
> >> As always, glad to review any additional PR's w/ any new polisher
> >> features & enhancements.
> >>
> >>   -Mo
> >>
> > Yeah, Mo.
> > I'm wondering if the complexity should live in polisher or gem2rpm.
> > It seems strange to use gem2rpm for initial rpms and polisher for updates.
> >
> > If we can solve both initial and updates to a spec in gem2rpm, we can
> > eliminate similar logic in both.
> >
> 
> There are some common aspects to the process and some differences. For
> creation gem2rpm uses erb-based templates to generate new spec files.
> For updating, polisher parses the spec & attempts to interpolate gem/rpm
> contents.
> 
> There are tradeoffs either way, generating a new spec gives you a fresh
> start, but updating it can incorporate existing changes which still apply.
> 
> As it stands polisher currently does alot of the parsing / updating
> legwork. Of course there are edge cases which can be addressed, but
> those should be able to be taken care of w/ small / targeted PR's (as
> issues are discovered).
> 
>   -Mo
> 

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

Thanks,

-- 
Joe Rafaniello


More information about the ruby-sig mailing list