Packaging guidelines - Bundler

[Vít Ondruch]

Dne 4.1.2012 15:35, Mo Morsi napsal(a):
> On 01/04/2012 09:24 AM, Vít Ondruch wrote:
>> Dne 4.1.2012 15:10, Mo Morsi napsal(a):
>>> On 01/04/2012 08:56 AM, Vít Ondruch wrote:
>>>> Dne 4.1.2012 14:43, Mo Morsi napsal(a):
>>>>> On 01/03/2012 01:18 PM, Vít Ondruch wrote:
>>>>>> Dne 3.1.2012 18:40, Michael Stahnke napsal(a):
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jan 3, 2012 at 7:21 AM, Vít Ondruch <vondruch at redhat.com 
>>>>>>> <mailto:vondruch at redhat.com>> wrote:
>>>>>>>
>>>>>>>     Hi everybody,
>>>>>>>
>>>>>>>     I am wondering if we should mention Bundler in Ruby's
>>>>>>>     packaging guidelines and what should be recommendations? Or
>>>>>>>     should we leave it in gray area of guidelines?
>>>>>>>
>>>>>
>>>>> The root issue isn't using bundler per-se, rather the gem 
>>>>> dependencies listed in the rpm spec, gem spec, and bundler's 
>>>>> Gemfile may become out of sync.
>>>>>
>>>>> So long as the guidelines has something to address this I think 
>>>>> we'll be fine. Something along the lines of it is up to the 
>>>>> package maintainer to ensure all the gem dependency subsystems 
>>>>> (rpm, gem, and bundler) are kept in sync.
>>>>
>>>> I am afraid of scenario such as:
>>>>
>>>> * Having RPM packaged Rails application
>>>> * Having Gemfile.lock present
>>>> * Update of Rack to 1.4 version.
>>>>
>>>> Now how you will ensure after such update that you did not broke 
>>>> the application? Even though you can find what packages depends on 
>>>> Rack and you check their .gemspec, how you will find the 
>>>> applications with Gemfile.lock? How you will find packages where 
>>>> Gemfile states 'rack', '1.3'?
>>>
>>> If the rpm spec, gemspec, and gemfile are required to be kept in 
>>> sync, this isn't an issue.
>>>
>>> The maintainer of the rails application would need to represent all 
>>> their dependencies in the rpm spec and the Gemfile lock. Afterall 
>>> they best know what the various versions of their application 
>>> require in terms of the various versions of underlying dependencies, 
>>> and can update their package accordingly (to make it is as 
>>> restrictive or as flexible as desired).
>>>
>>> In this case, trying to update Rack would break things at both the 
>>> rpm level, the gem level, and the bundler level. Thus first and 
>>> foremost the system wouldn't permit it if doing the update via rpm, 
>>> and if doing it via gem / bundler, it wouldn't matter as the rpm 
>>> version would still be present.
>>>
>>
>> If you update rack, you should ensure that you did not broken the 
>> activesupport (possibly fixing its .gemspec and may be some failures).
>
> Why? Nowhere else in Fedora is a package maintainer required to make 
> sure that all the dependencies on that package do not break with an 
> update.
>
> Rather, the policy is to keep versions stable within a Fedora release, 
> and if a major package is being updated in a new release, to give 
> plenty of notification via the mailing lists and what not.

Yes, we should cultivate this policy. Updates just in Rawhide if possible.

>
> Jeroen is the owner or rubygem-rack, I am the owner of 
> rubygem-activesupport. If he wishes to update rack in the next version 
> of Fedora he should announce on the ruby-sig mailing list this 
> upcoming update, making the rpms available as soon as he can (either 
> hosted by himself or via rawhide), and it is up to me to make sure 
> rubygem-activesupport doesn't break.
>
> If I need to update activesupport to ensure this, I should do the 
> same, eg announce on list and make the rpms available. This way the 
> community is kept in sync and we can discuss updates / resolve issues 
> before hand.

Sure, that is how it works, but you are supported by tools. You'll do 
simple repoquery --whatrequires or --requires and you know what should 
be fixed, but you can't list relevant Gemfiles.


Vit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/ruby-sig/attachments/20120104/e3940932/attachment.html>