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