requirements for native gems not free text?

Jordi Massaguer Pla jmassaguerpla at suse.de
Wed Jan 30 11:00:33 UTC 2013


Quoting Gary Weaver <garysweaver at gmail.com>:

> I think it would be better to stick with the current DSL looking
> "add_*_dependency" type of thing and do a require at the top of the Gemfile
> that would load that gem to extend Gem::Specification.
>
> And since the name and version of the dependency could depend on platform
> and tool used to list the loaded libraries, maybe the extending gem should
> define command name specific methods, like for OS X that provides 'otool'
> as a dynamic library lister:
>
> spec.add_native_dependency 'otool', 'libSystem.B.dylib', '~> 159.1', '>=
> 159.1.0'
>
> so that that gem would maybe do:
> otool -L `which ruby`
>
> and then parse that output to find the current version.
>
> Then, for linux, that gem would use ldd and you'd need to specify:
>
> spec.add_native_dependency 'ldd', 'libm.so.6', ['GLIBC_2.2.5'] # if array,
> it is a list of valid versions (for versions that aren't x(.x)(.x))
>
> Where your rubygems extending native library checking gem would do:
> ldd -v `which ruby`
>
> But, I don't think it is as clear with Windows. Some ways of checking DLLs
> are discussed here:
>
> http://stackoverflow.com/questions/602802/command-line-tool-to-dump-windows-dll-version
> http://superuser.com/questions/381276/what-are-some-nice-command-line-ways-to-inspect-dll-exe-details
>
> Nothing there that is built-in that I see- maybe you could bundle sigcheck
> with the gem, though, if the license/owner allows that.
>
> So, it wouldn't be terribly difficult to make it easy to use and visually
> similar to the existing rubygems spec, but the native specific stuff is not
> as straightforward, and ldd, etc. may potentially behave differently
> depending on version, making that difficult. Wouldn't be trivial, overall,
> to say the least, but sound like fun if you like long ongoing project
> maintenance.


I was just thinking on something very simple. By adding metadata that  
contains the name of the libraries required, this metadata can be  
retrievend and, in most linux platforms, you can use rpm or dpkg to  
know if that it is installed. But using rpm or dpkg would be something  
run by the user, rubygems should only provide the name of the library,  
that I believe should be the same for most linux platforms.

Does it has sense?

>
> On Mon, Jan 28, 2013 at 6:22 AM, Jordi Massaguer Pla
> <jmassaguerpla at suse.de>wrote:
>
>> Quoting Evan Phoenix <evan at phx.io>:
>>
>>  See below.
>>>
>>> --
>>> Evan Phoenix // evan at phx.io
>>>
>>>
>>> On Saturday, January 26, 2013 at 10:06 AM, Jordi Massaguer Pla wrote:
>>>
>>>  Does this mean we could have something like:
>>>>
>>>> metadata["linux_requirements"] = ["libMagick.so >= 6.6.2"]
>>>>
>>> Yes, that's correct.
>>>
>>>>
>>>> where can I find more information on the metadata?
>>>>
>>>
>>> We haven't written many docs on it yet, but here is some:
>>> https://github.com/rubygems/**rubygems/blob/master/lib/**
>>> rubygems/specification.rb#L23-**L35<https://github.com/rubygems/rubygems/blob/master/lib/rubygems/specification.rb#L23-L35>
>>>
>>
>>
>> That looks very interesting. I was thinking thought that what would make
>> life easier is that everyone was using the same "key". Like
>> "linux_requirements" for example.
>>
>> Do you think that there could be some recomendations on which key to use
>> for that purpose? I would not mind sending PR to every native gem I use,
>> but I do not know which key to use.
>>
>>
>>
>>> ______________________________**_________________
>>> RubyGems-Developers mailing list
>>> http://rubyforge.org/projects/**rubygems<http://rubyforge.org/projects/rubygems>
>>> RubyGems-Developers at rubyforge.**org <RubyGems-Developers at rubyforge.org>
>>> http://rubyforge.org/mailman/**listinfo/rubygems-developers<http://rubyforge.org/mailman/listinfo/rubygems-developers>
>>>
>>>
>>
>> ______________________________**_________________
>> RubyGems-Developers mailing list
>> http://rubyforge.org/projects/**rubygems<http://rubyforge.org/projects/rubygems>
>> RubyGems-Developers at rubyforge.**org <RubyGems-Developers at rubyforge.org>
>> http://rubyforge.org/mailman/**listinfo/rubygems-developers<http://rubyforge.org/mailman/listinfo/rubygems-developers>
>>
> _______________________________________________
> RubyGems-Developers mailing list
> http://rubyforge.org/projects/rubygems
> RubyGems-Developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers
>




More information about the RubyGems-Developers mailing list