Packaging guidelines - Bundler

[Mo Morsi]

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.

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.

I'll fully admit this isn't always the standard practice but this is 
more of a community issue and while the the tooling / guidelines can 
address these practices, it is up to the community to enforce them.





> If activesupport still works, everything what depends on it should 
> also work in theory. However, several levels up is sitting Gemfile 
> which needs to be adjusted to new rack. How you would know that? You 
> can't and this is what I am afraid of.

If an other package depends on rack directly, the maintainer should 
ensure it works when they receive notification rack is being updated on 
the mailing list.

If the package only depends on activesupport but mistakingly lists the 
rack dependency, a bug should be files upstream to resolve this.

   -Mo

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