gem2rpm and upgrades of existing rpms

[Mo Morsi]

On 06/25/2014 11:56 AM, Joe Rafaniello wrote:
> ----- 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:

That's not what I said at all.

"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."



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

We're beating on a dead horse here. Obviously I can't stop you from
sending patches / following any approach you want. I can only recommend
what I believe will / won't work based on my experience with packaging
and the automation effort.


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

Again to reiterate my question, have you actually tried developing a
solution to this before and have run into problems? Or is this just
speculation?

Each version of the guidelines is well documented. We can add some
command line and API flags to Polisher where the user can specify the
versions there are upgrading from/to (if not inferred).

  -Mo