Re: Packaging rack-based applications for Fedora
Dne 10.2.2011 18:33, David Lutterkort napsal(a):
On Thu, 2011-02-10 at 17:12 +0100, Michal Fojtik wrote:
* Where should be these application installed?
My preference is to install them inside /usr/lib or /usr/share directory.
I wouldn't do that - it's only extra work during packaging, for no added
benefit
Well I would say that we are speaking about first Sinatra application
which is going to Fedora (at least I am not aware of any other). So if
we don't do it right for the first time, then we will create dangerous
precedence. Actually, the installation into /usr/share is quite
straightforward. Here are steps how to proceed:
1) Lets assume the application is packaged as a gem for convenience
2) Do gem install as usually.
3) Copy the %{buildroot}%{geminstdir} into /usr/share (the version
should be probably omitted?)
4) Instead of /bin/appname, which is usually provided by rubygems should
be used script which is static. Please see attached deltacloudd-orig
(provided by rubygems) and its modified version in deltacloudd file.
The RDoc documentation which would be available from Gem should be
replaced by its Man alternative, as it should be for every application
(and this is commonly not true for executable gems).
Pros:
1) Ruby load path pollution is avoided.
1a) Since every gem is automatically added into load path, there might
be unnecessary conflicts. For example the deltacloud-core has some
Sinatra extension in lib/sinatra/ folder and these extension can
conflict with installed gems.
1b) Every gem added to Ruby slows down ruby require performance.
Although it looks to be negligible penalty, it is unnecessary penalty at
least.
2) Ruby application has nothing to do with RubyGems. If they are
provided as a gem, it just for convenience, but it does not mean anything.
3) This approach follows the way how the Redmine is packaged in Debian
for example.
Cons:
1) May be slightly more work for packager? But work which is done once.
Vit
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Re: Packaging rack-based applications for Fedora
Well,
Vít Ondruch wrote, at 02/15/2011 07:08 PM +9:00:
Dne 10.2.2011 18:33, David Lutterkort napsal(a):
On Thu, 2011-02-10 at 17:12 +0100, Michal Fojtik wrote:
* Where should be these application installed?
My preference is to install them inside /usr/lib or /usr/share directory.
I wouldn't do that - it's only extra work during packaging, for no added
benefit
Well I would say that we are speaking about first Sinatra application
which is going to Fedora (at least I am not aware of any other). So if
we don't do it right for the first time, then we will create dangerous
precedence. Actually, the installation into /usr/share is quite
straightforward. Here are steps how to proceed:
1) Lets assume the application is packaged as a gem for convenience
2) Do gem install as usually.
3) Copy the %{buildroot}%{geminstdir} into /usr/share (the version
should be probably omitted?)
4) Instead of /bin/appname, which is usually provided by rubygems should
be used script which is static. Please see attached deltacloudd-orig
(provided by rubygems) and its modified version in deltacloudd file.
The RDoc documentation which would be available from Gem should be
replaced by its Man alternative, as it should be for every application
(and this is commonly not true for executable gems).
Pros:
1) Ruby load path pollution is avoided.
1a) Since every gem is automatically added into load path, there might
be unnecessary conflicts. For example the deltacloud-core has some
Sinatra extension in lib/sinatra/ folder and these extension can
conflict with installed gems.
Um? gem 'foo', '= ver' is actually intended to specify load path and
its order, and to avoid such conflict. You can check this by actually checking
the load path.
1b) Every gem added to Ruby slows down ruby require performance.
Although it looks to be negligible penalty, it is unnecessary penalty at
least.
I don't think this is not the supporting reason for your way of
packaging.
2) Ruby application has nothing to do with RubyGems. If they are
provided as a gem, it just for convenience, but it does not mean anything.
But there is no need we should avoid using rubygems... Or you have strong
reason we mustn't install rubygems?
3) This approach follows the way how the Redmine is packaged in Debian
for example.
Please don't think of Debian's way.
Cons:
1) May be slightly more work for packager? But work which is done once.
I can't see the benefit of such complicated way of packaging. Let's keep
it simple unless unavoidable.
- By the way, I can't see your attached spec or srpm.
Regards,
Mamoru
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Re: Packaging rack-based applications for Fedora
Michal Fojtik wrote, at 02/11/2011 01:12 AM +9:00: Hi, I want to ask if there are any policies or guidelines for packaging 'rack-based' (Sinatra/Rails/..) projects for Fedora. Since I started packaging Deltacloud API (Sinatra app) I got into situlation that I want to install it as a gem and then run it by 'deltacloudd' command (will basically spawn thin). * Should be they marked as a 'rubygem-*'? My opinion is *no*, because they will not provide 'gem' functionality, since they are not 'libraries'. Just noting that my rubygem based rawhide packages stats [1] script is assuming that these srpms are named as rubygem-foo (and the base gem file is uploaded on rubygems.org). It is simple that if the pkgs is created basing on gem file, we simply name it as rubygem-foo. You can add Provides: deltacloudd = foo or even create empty subpackage if you want. [1] like: http://lists.fedoraproject.org/pipermail/ruby-sig/2011-February/000436.html Regards, Mamoru ___ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Re: Packaging rack-based applications for Fedora
On 15/02/11 20:49 +0900, Mamoru Tasaka wrote: Michal Fojtik wrote, at 02/11/2011 01:12 AM +9:00: Hi, I want to ask if there are any policies or guidelines for packaging 'rack-based' (Sinatra/Rails/..) projects for Fedora. Since I started packaging Deltacloud API (Sinatra app) I got into situlation that I want to install it as a gem and then run it by 'deltacloudd' command (will basically spawn thin). * Should be they marked as a 'rubygem-*'? My opinion is *no*, because they will not provide 'gem' functionality, since they are not 'libraries'. Just noting that my rubygem based rawhide packages stats [1] script is assuming that these srpms are named as rubygem-foo (and the base gem file is uploaded on rubygems.org). It is simple that if the pkgs is created basing on gem file, we simply name it as rubygem-foo. You can add Provides: deltacloudd = foo or even create empty subpackage if you want. I like the approach with empty subpackage, since we are not an library nor offering any library functionality, but we depend on Ruby libraries. Can this subpackage ship init scripts and configuration files for Fedora? Maybe it will worth to do some guideline, or edit guidelines Wiki and mention this thread there for future packages based on Rack (eg. Redmine or other Sinatra projects, etc.) -- Michal [1] like: http://lists.fedoraproject.org/pipermail/ruby-sig/2011-February/000436.html Regards, Mamoru ___ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig -- Michal Fojtik, mfoj...@redhat.com Deltacloud API: http://deltacloud.org ___ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Re: Packaging rack-based applications for Fedora
Dne 15.2.2011 12:35, Mamoru Tasaka napsal(a):
Well,
Vít Ondruch wrote, at 02/15/2011 07:08 PM +9:00:
Dne 10.2.2011 18:33, David Lutterkort napsal(a):
On Thu, 2011-02-10 at 17:12 +0100, Michal Fojtik wrote:
* Where should be these application installed?
My preference is to install them inside /usr/lib or /usr/share directory.
I wouldn't do that - it's only extra work during packaging, for no added
benefit
Well I would say that we are speaking about first Sinatra application
which is going to Fedora (at least I am not aware of any other). So if
we don't do it right for the first time, then we will create dangerous
precedence. Actually, the installation into /usr/share is quite
straightforward. Here are steps how to proceed:
1) Lets assume the application is packaged as a gem for convenience
2) Do gem install as usually.
3) Copy the %{buildroot}%{geminstdir} into /usr/share (the version
should be probably omitted?)
4) Instead of /bin/appname, which is usually provided by rubygems should
be used script which is static. Please see attached deltacloudd-orig
(provided by rubygems) and its modified version in deltacloudd file.
The RDoc documentation which would be available from Gem should be
replaced by its Man alternative, as it should be for every application
(and this is commonly not true for executable gems).
Pros:
1) Ruby load path pollution is avoided.
1a) Since every gem is automatically added into load path, there might
be unnecessary conflicts. For example the deltacloud-core has some
Sinatra extension in lib/sinatra/ folder and these extension can
conflict with installed gems.
Um? gem 'foo', '= ver' is actually intended to specify load path and
its order, and to avoid such conflict. You can check this by actually checking
the load path.
Well, if the required file is not found on loadpath already, it will
fallbacks to rubygems and rubygems will try every gem/lib path to
require the file. So your gem command can't help here.
1b) Every gem added to Ruby slows down ruby require performance.
Although it looks to be negligible penalty, it is unnecessary penalty at
least.
I don't think this is not the supporting reason for your way of
packaging.
Performance is everytime good reason and should not be overseen.
2) Ruby application has nothing to do with RubyGems. If they are
provided as a gem, it just for convenience, but it does not mean anything.
But there is no need we should avoid using rubygems... Or you have strong
reason we mustn't install rubygems?
This is not discussion about using/notusing rubygems itself. I am not
suggesting that we should avoid rubygems, while I admit there are also
different solutions which replaces rubygems entirely in some or all
rubygem domains (http://hellorip.com/, http://gembundler.com/,
https://github.com/jbarnette/isolate).
I am just trying to point out that not everything, what available as
rubygem, has to be necessarily present as rubygem in scope of Fedora,
not even mention FHS.
If we have application Foo, it should be placed under /usr/lib,
/usr/lib64, /usr/share and not under /usr/lib/ruby/gems/1.8/gems/foo .
3) This approach follows the way how the Redmine is packaged in Debian
for example.
Please don't think of Debian's way.
At first, if you read guidelines, inspiration from other distributions
is encouraged:
http://fedoraproject.org/wiki/How_to_create_an_RPM_package#Reuse_existing_package_information
At second, it conforms not only Debian, but also FHS
Cons:
1) May be slightly more work for packager? But work which is done once.
I can't see the benefit of such complicated way of packaging. Let's keep
it simple unless unavoidable.
- By the way, I can't see your attached spec or srpm.
This thread started because I am doing review for this package:
https://bugzilla.redhat.com/show_bug.cgi?id=674060
This approach is equivalently complicated to installing the gem in %prep
section and later copying the folder structure in to %{buildroot} in
%install step. So I hesitate to speak about complication at all.
Btw I forgot to attach the deltacloudd and deltacloudd.orig files
mentioned in previous mail :/
Vit
#!/usr/bin/ruby
root_path = File.join('/', 'usr', 'share', 'deltacloud-core')
$:.unshift File.join(root_path, 'lib')
load File.join(root_path, 'bin', 'deltacloudd')
#!/usr/bin/ruby
#
# This file was generated by RubyGems.
#
# The application 'deltacloud-core' is installed as part of a gem, and
# this file is here to facilitate running it.
#
require 'rubygems'
version = = 0
if ARGV.first =~ /^_(.*)_$/ and Gem::Version.correct? $1 then
version = $1
ARGV.shift
end
gem 'deltacloud-core', version
load Gem.bin_path('deltacloud-core', 'deltacloudd', version)
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Re: Packaging rack-based applications for Fedora
On 02/15/2011 01:26 PM, Vít Ondruch wrote: 1b) Every gem added to Ruby slows down ruby require performance. Performance is everytime good reason and should not be overseen. Hi, this ^ is interesting. I am just starting with Ruby. Do you have any links to read regarding these performance problems? Thanks FYI I am finishing my work on Foreman Proxy package which is Sinatra too. Going to submit soon. We don't have a rubygem and there are no plans to release it. This is the simple scenario then I guess. BTW I have submitted five (one is irrelevant since Rails 3 hit the rawhide) dependant libraries for The Foreman. Bugzilla links follow if you are interested. Please note these are my first Ruby packages. So be nice :-) http://theforeman.org/projects/foreman/wiki/ForemanFedoraPackaging ps - thanks Vit Michal for their support during my first Ruby packaging efforts -- Later, Lukas lzap Zapletal ___ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Re: Packaging rack-based applications for Fedora
BTW: Redmine package: https://bugzilla.redhat.com/show_bug.cgi?id=499959
Redmine is apparently going to be installed into %{_datadir}. The only
difference is how was the original source obtained. For deltacloud-core
it is gem while for redmine it is tar.gz, but at the end, it could be
zip or whatever else, it is just archive.
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Re: Packaging rack-based applications for Fedora
Dne 15.2.2011 13:39, Lukas Zapletal napsal(a): On 02/15/2011 01:26 PM, Vít Ondruch wrote: 1b) Every gem added to Ruby slows down ruby require performance. Performance is everytime good reason and should not be overseen. Hi, this ^ is interesting. I am just starting with Ruby. Do you have any links to read regarding these performance problems? Thanks Well I can remember the thread regarding RubyInstaller for Windows, but there are probably others: http://groups.google.com/group/rubyinstaller/browse_thread/thread/bee1d21264ac48b9 Vit ___ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Re: Packaging rack-based applications for Fedora
Vít Ondruch wrote, at 02/15/2011 09:26 PM +9:00:
Pros:
1) Ruby load path pollution is avoided.
1a) Since every gem is automatically added into load path, there might
be unnecessary conflicts. For example the deltacloud-core has some
Sinatra extension in lib/sinatra/ folder and these extension can
conflict with installed gems.
Um? gem 'foo', '= ver' is actually intended to specify load path and
its order, and to avoid such conflict. You can check this by actually
checking
the load path.
Well, if the required file is not found on loadpath already, it will fallbacks
to rubygems and rubygems will try every gem/lib path to require the file. So
your gem command can't help here.
But even if you put everything to %_datadir, if the required file is not found
ruby will search it under loadpath, and if it is not found ruby will complain
it was not found. Unless you specify first all loadpaths (including files
provided
by other pkgs), your method will fail anyway.
1b) Every gem added to Ruby slows down ruby require performance.
Although it looks to be negligible penalty, it is unnecessary penalty at
least.
I don't think this is not the supporting reason for your way of
packaging.
Performance is everytime good reason and should not be overseen.
And you have some benchmark? And the delay happens at any time (i.e. not
only when the application launches)?
2) Ruby application has nothing to do with RubyGems. If they are
provided as a gem, it just for convenience, but it does not mean anything.
But there is no need we should avoid using rubygems... Or you have strong
reason we mustn't install rubygems?
This is not discussion about using/notusing rubygems itself.
I am not suggesting that we should avoid rubygems, while I admit there
are also different solutions which replaces rubygems entirely in some or all
rubygem domains
(http://hellorip.com/, http://gembundler.com/,
https://github.com/jbarnette/isolate).
I am just trying to point out that not everything, what available as rubygem,
has to be
necessarily present as rubygem in scope of Fedora, not even mention FHS.
I am saying that if the upstream are using rubygems, let's use rubygems as
the upstream does. It is again simple. Again what I am saying is that let's
make it
simple.
If we have application Foo, it should be placed under /usr/lib, /usr/lib64,
/usr/share
and not under /usr/lib/ruby/gems/1.8/gems/foo .
Sorry but actually I am very tired of the discussion of as this is application
or as this is a module or so. This is actually one of the annoyance I
frequently
meet during review requests (this never-ending discussion happens not only on
ruby related pkgs). Judgment of this type differs between each reviewer
and unless we set an apparent criterion this type of distinction.
And please keep in mind that reviewers are not always familiar with ruby.
3) This approach follows the way how the Redmine is packaged in Debian
for example.
Please don't think of Debian's way.
At first, if you read guidelines, inspiration from other distributions is
encouraged:
http://fedoraproject.org/wiki/How_to_create_an_RPM_package#Reuse_existing_package_information
Again don't think of Debian. Debian has confusing packaging schemas on
many points and as Debian does is not valid on Fedora in many ways.
At second, it conforms not only Debian, but also FHS
Putting everyting under /usr/lib is easier way to follow FHS, actually
(apart from /usr/bin or so).
Cons:
1) May be slightly more work for packager? But work which is done once.
I can't see the benefit of such complicated way of packaging. Let's keep
it simple unless unavoidable.
- By the way, I can't see your attached spec or srpm.
This thread started because I am doing review for this package:
https://bugzilla.redhat.com/show_bug.cgi?id=674060
This approach is equivalently complicated to installing the gem in %prep
section and later copying
the folder structure in to %{buildroot} in %install step. So I hesitate to
speak about complication at all.
What is complicated is that you break the file structure what gem install
does and add some
wrapper script, while it is not actually needed.
Regards,
Mamoru
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Re: Packaging rack-based applications for Fedora
Vít Ondruch wrote, at 02/15/2011 11:44 PM +9:00: But even if you put everything to %_datadir, if the required file is not found ruby will search it under loadpath, and if it is not found ruby will complain it was not found. Unless you specify first all loadpaths (including files provided by other pkgs), your method will fail anyway. 1) The best for the application is if it runs in isolation, therefore there were invented bundler and isolate. 2) For running of application, it is sufficient to load the application dependencies using: RUBYOPT=Ipath/to/my/dependency1 Ipath/to/some/gem/wherever/it/is As you see, by specifying the explictit RUBYOPT, there are not rubygems required at all (speaking about R1.8, for R1.9 it is a bit different). The dependencies are maintained by RPM, therefore it is safe to use it on Fedora. So you there is no fallback. And the same apply for rubygems. I assume you are already familiar with these posts: http://tomayko.com/writings/require-rubygems-antipattern http://yehudakatz.com/2009/07/24/rubygems-good-practice/ You are just saying that it can be done without rubygems... With rubygems if we set gem foo in advance there is no fallback. 1b) Every gem added to Ruby slows down ruby require performance. Although it looks to be negligible penalty, it is unnecessary penalty at least. I don't think this is not the supporting reason for your way of packaging. Performance is everytime good reason and should not be overseen. And you have some benchmark? And the delay happens at any time (i.e. not only when the application launches)? I don't have benchmark. The delay of application start might by significant. Also, if you are using rails 3 in development mode, they are reloading everything for each request. Another example where you feel such penalty is when you are using autotest for example. If you see signicicant delay, teaching the upstream not to use gem, or modifying rubygems is much preferable, for people not only on Fedora but also people not using Fedora. Not discussing with the upstream does not help. I just think that if the upstream uses rubygems, there is some reason (maybe just because it is easier to develop with gem). I am just trying to point out that not everything, what available as rubygem, has to be necessarily present as rubygem in scope of Fedora, not even mention FHS. I am saying that if the upstream are using rubygems, let's use rubygems as the upstream does. It is again simple. Again what I am saying is that let's make it simple. It starts to look, that it would make the things easier for Fedora if the upstream stop providing gem and starts providing tar.gz instead. But this does not make a sense at all. Note that if some significant packaging change happens submitting re-review request is preferred, even if not changing the srpm name. It is quite imaginable that switching gem to tar.gz may mean some additional change in packaging. If we have application Foo, it should be placed under /usr/lib, /usr/lib64, /usr/share and not under /usr/lib/ruby/gems/1.8/gems/foo . Sorry but actually I am very tired of the discussion of as this is application or as this is a module or so. This is actually one of the annoyance I frequently meet during review requests (this never-ending discussion happens not only on ruby related pkgs). Judgment of this type differs between each reviewer and unless we set an apparent criterion this type of distinction. And please keep in mind that reviewers are not always familiar with ruby. I am asking for standardization of packaging Ruby applications, to prevent future confusion. And honestly, Rails and Sinatra applications are simply applications. So what is application or not is not obvious, especially for reviewers not familiar with ruby, and this happens also in non-ruby packages. Unless you have a clear criterion about how we can judge what is application or not (which is apparent for all reviewers), this just causes unneeded confusion. 3) This approach follows the way how the Redmine is packaged in Debian for example. Please don't think of Debian's way. At first, if you read guidelines, inspiration from other distributions is encouraged: http://fedoraproject.org/wiki/How_to_create_an_RPM_package#Reuse_existing_package_information Again don't think of Debian. Debian has confusing packaging schemas on many points and as Debian does is not valid on Fedora in many ways. Yes, they might be invalid, but one can learn even from other's errors. At second, it conforms not only Debian, but also FHS Putting everyting under /usr/lib is easier way to follow FHS, actually (apart from /usr/bin or so). Easier doesn't mean correct. We should distinguish between. As FHS states: The /usr/share hierarchy is for all read-only architecture independent data files. Much of this data originally lived in /usr (man, doc) or /usr/lib (dict, terminfo, zoneinfo).
Re: Packaging rack-based applications for Fedora
On Thu, 10 Feb 2011 17:12:32 +0100, Michal Fojtik mfoj...@redhat.com wrote: Hi, I want to ask if there are any policies or guidelines for packaging 'rack-based' (Sinatra/Rails/..) projects for Fedora. Yes, there's a set of policies at: http://fedoraproject.org/wiki/Packaging:Ruby#Ruby_Gems * Where should be these application installed? My preference is to install them inside /usr/lib or /usr/share directory. This should become clear from the documentation I referred to. * Should be they marked as a 'rubygem-*'? My opinion is *no*, because they will not provide 'gem' functionality, since they are not 'libraries'. If the distribution method is gem packages (e.g. '.gem' files), and the command to install them originally is 'gem install', then yes the main package should be named 'rubygem-*'. That said, however, if the '.gem' is now only a part of the source RPM package, but not the main part, while you could %package -n rubygem-* the gem as a sub-package, you oughta split the sub-package containing the ruby gem into a source package 'rubygem-*'. That said, if the main package is 'rubygem-*' but this does not seem appropriate (e.g. users then need to 'yum install rubygem-deltacloud' where you want it to be 'yum install deltacloud', have you thought of providing a 'deltacloud' meta-sub-package? This sub-package would not necessarily contain any other files then perhaps just the documentation, but pull in all the requirements including the rubygem-* package. * What if they are already packaged as 'gem', should be they installed using 'gem install'? My opinion here is that it doesn't matter what extension is used, it's still 'packaged source', so it can be 'unpacked' by gem install. I'm not sure I understand the question; if they are already packaged as gem, they should be installed using 'gem install'. If 'gem install' is to be used to install the package, then the source file extension should be '.gem'. -- Jeroen ___ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Re: Packaging rack-based applications for Fedora
Dne 10.2.2011 17:21, Jeroen van Meeuwen napsal(a): On Thu, 10 Feb 2011 17:12:32 +0100, Michal Fojtikmfoj...@redhat.com wrote: Hi, I want to ask if there are any policies or guidelines for packaging 'rack-based' (Sinatra/Rails/..) projects for Fedora. Yes, there's a set of policies at: http://fedoraproject.org/wiki/Packaging:Ruby#Ruby_Gems Actually we are speaking about Ruby applications in general I would say. Let say I have Foo application which is based on Shoes for example. How should I package it? Is there already some sample application packaged? Or what about Rails or Sinatra applications? Is there already some of them packaged, which could be taken as an example? These applications are not typically packaged as gems, while they can be for convenience. Vit ___ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Re: Packaging rack-based applications for Fedora
On Thu, 2011-02-10 at 17:12 +0100, Michal Fojtik wrote:
* Where should be these application installed?
My preference is to install them inside /usr/lib or /usr/share directory.
I wouldn't do that - it's only extra work during packaging, for no added
benefit.
* Should be they marked as a 'rubygem-*'?
My opinion is *no*, because they will not provide 'gem' functionality,
since they are not 'libraries'.
When I wrote the original ruby packaging guidelines, I could have sworn,
I put in an exception for applications that happen to be written in
Ruby; there's no good reason to call an application rubygem-app if
nobody is going to use it as a ruby library.
If users care more about the app than the fact that it's written in
ruby, it should be permissible to drop the {ruby,rubygem}-* prefixes.
And at least puppet and facter follow this pattern.
* What if they are already packaged as 'gem', should be they installed
using 'gem install'?
I'd do that just to keep things simple.
David
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
