----- 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(a)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