----- 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 _______________________________________________ ruby-sig mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
