Packaging guidelines - Bundler

[Mo Morsi]

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.



>
> This seems to be fragile and huge overload for packagers.
>
>>
>> This is the same for end-users, eg it is up to them to make sure they 
>> are using an application that works w/ the ruby packages shipped on 
>> the given Fedora version.
>>
>>
>
> For end user, it's "easy" I would say. I know my application, I know 
> when I update the system, if something breaks, it is possible to 
> localize the issue easily.

'Easy' can take on multiple meanings, it's not out of the question for 
end-users to use a slightly older version / branch of an application if 
that satisfies all their requirements and will 'just work' with the 
dependencies installed on their system.

   -Mo


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