public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] ruby gems vs. ebuilds
@ 2006-10-05 20:03 Roy Wright
  2006-10-05 20:16 ` Boris Fersing
  0 siblings, 1 reply; 3+ messages in thread
From: Roy Wright @ 2006-10-05 20:03 UTC (permalink / raw
  To: gentoo-dev

Howdy,

Can someone point me to any documentation on why ebuilds are
being created for ruby gems?

Gem is the a nice, easy to use, standard package manager for ruby.

The problem that I see is if you install the same package via both
gem and portage all sorts of bad things happen.  For the curious,
use gem to install rake, then portage to install rake, then try to
use rake...  Hint, emerge --unmerge is your friend.

The real problem is when you now install a package that has
ruby dependencies (example kazehakase-0.4.1).  Real easy to
to have portage trash your previous gem install.

Wouldn't make more sense to have the ebuilds front-end gem vs.
doing a config & make & make instlal?  Then if you had installed
via gem, then portage, the gem would just be re-installed, not
installed differently.

TIA,
Roy

-- 

echo "spzxAdjtdp/dpn" | perl -pe 's/(.)/chr(ord($1)-1)/ge'
-- 
gentoo-dev@gentoo.org mailing list



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [gentoo-dev] ruby gems vs. ebuilds
  2006-10-05 20:03 [gentoo-dev] ruby gems vs. ebuilds Roy Wright
@ 2006-10-05 20:16 ` Boris Fersing
  2006-10-05 21:03   ` Roy Wright
  0 siblings, 1 reply; 3+ messages in thread
From: Boris Fersing @ 2006-10-05 20:16 UTC (permalink / raw
  To: gentoo-dev

2006/10/5, Roy Wright <royw@cisco.com>:
> Howdy,
>
> Can someone point me to any documentation on why ebuilds are
> being created for ruby gems?
>
> Gem is the a nice, easy to use, standard package manager for ruby.
>
> The problem that I see is if you install the same package via both
> gem and portage all sorts of bad things happen.  For the curious,
> use gem to install rake, then portage to install rake, then try to
> use rake...  Hint, emerge --unmerge is your friend.
>
> The real problem is when you now install a package that has
> ruby dependencies (example kazehakase-0.4.1).  Real easy to
> to have portage trash your previous gem install.
>
> Wouldn't make more sense to have the ebuilds front-end gem vs.
> doing a config & make & make instlal?  Then if you had installed
> via gem, then portage, the gem would just be re-installed, not
> installed differently.

Hi,

AFAIK, the ruby related ebuilds use gem. For example rails has in his ebuild :

"inherit ruby gems"

and if you look in the gems eclass :

<code>
gems_src_install() {
    gems_location

    if [ -z "${MY_P}" ]; then
        GEM_SRC=${DISTDIR}/${P}
    else
        GEM_SRC=${DISTDIR}/${MY_P}
    fi

    if use doc; then
        myconf="--rdoc"
    else
        myconf="--no-rdoc"
    fi

    dodir ${GEMSDIR}
    gem install ${GEM_SRC} -v ${PV} ${myconf} -l -i ${D}/${GEMSDIR} ||
die "gem install failed"

    if [ -d ${D}/${GEMSDIR}/bin ] ; then
        exeinto /usr/bin
        for exe in ${D}/${GEMSDIR}/bin/* ; do
            doexe ${exe}
        done
    fi
}
</code>

And it's the same for rake !

The problem might be (that's a supposition only) that gem installs the
files in the image which will be merged to the system by portage and
doesn't install the files directly in the "real" system.

or maybe did I miss something ?

Regards,

Boris.
>
> TIA,
> Roy
>
> --
>
> echo "spzxAdjtdp/dpn" | perl -pe 's/(.)/chr(ord($1)-1)/ge'
> --
> gentoo-dev@gentoo.org mailing list
>
>


-- 
Quiconque me parle de Dieu en veut à ma bourse ou à ma liberté.

-- 
gentoo-dev@gentoo.org mailing list



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [gentoo-dev] ruby gems vs. ebuilds
  2006-10-05 20:16 ` Boris Fersing
@ 2006-10-05 21:03   ` Roy Wright
  0 siblings, 0 replies; 3+ messages in thread
From: Roy Wright @ 2006-10-05 21:03 UTC (permalink / raw
  To: gentoo-dev

Boris Fersing wrote:
>
>
> AFAIK, the ruby related ebuilds use gem. For example rails has in his
> ebuild :
>
> "inherit ruby gems"
>
> and if you look in the gems eclass :
>
> [snip]
> And it's the same for rake !
>
> The problem might be (that's a supposition only) that gem installs the
> files in the image which will be merged to the system by portage and
> doesn't install the files directly in the "real" system.
>
> or maybe did I miss something ?
>
I stand corrected on the ebuilds.  I looked at another of my systems that
did not show the problem but had both rake gem and ebuild installed.

I'm wondering if it is something to do with "gem update".  I've been
running two systems in parallel, one for development, one for production.
The development system is running testing (~x86) while production system
is running stable (x86).  The development system is updated daily, the
production about once a month.  During my recent rails web app
development I've been careful to install the same gems at the same
time on both systems.  I also did a "gem update" on both system about
a day before I noticed the problem on my production system.

I verified that gem and portage are playing with the same version
rake-0.7.1.  Then I re-emerged rake on the production system. 
Running: rake --tasks in the application directory gives this:

cowboy current # rake --tasks
(in /var/rails/rodeo/releases/20061005042627)
/usr/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/validations.rb:334:
warning: `*' interpreted as argument prefix
/usr/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/validations.rb:363:
warning: `*' interpreted as argument prefix
/usr/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/migration.rb:224:
warning: instance variable @ignore_new_methods not initialized
/usr/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/migration.rb:224:
warning: instance variable @ignore_new_methods not initialized
/usr/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/connection_adapters/abstract/connection_specification.rb:41:
warning: method redefined; discarding old allow_concurrency=
/usr/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/connection_adapters/sqlserver_adapter.rb:456:
warning: method redefined; discarding old remove_column
/usr/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/active_record/connection_adapters/oracle_adapter.rb:119:
warning: (...) interpreted as grouped expression
/usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/request.rb:171:
warning: method redefined; discarding old relative_url_root
/usr/lib/ruby/1.8/cgi/session/pstore.rb:17: warning: method redefined;
discarding old []=
/usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/cgi_ext/raw_post_data_fix.rb:57:
warning: ambiguous first argument; put parentheses or even spaces
/usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/cgi_ext/raw_post_data_fix.rb:8:
warning: method redefined; discarding old initialize_query
/usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/session/active_record_store.rb:129:
warning: private attribute?
/usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/session/active_record_store.rb:179:
warning: method redefined; discarding old connection
/usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_view/helpers/prototype_helper.rb:641:
warning: ambiguous first argument; put parentheses or even spaces
/usr/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_view/helpers/prototype_helper.rb:874:
warning: `*' interpreted as argument prefix
/usr/lib/ruby/gems/1.8/gems/actionmailer-1.2.5/lib/action_mailer/vendor/tmail/facade.rb:486:
warning: method redefined; discarding old create_reply
/usr/lib/ruby/gems/1.8/gems/actionwebservice-1.1.6/lib/action_web_service/protocol/xmlrpc_protocol.rb:6:
warning: discarding old message
/usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:581: warning:
method redefined; discarding old []=
/usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:590: warning:
method redefined; discarding old []
/usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:595: warning:
method redefined; discarding old keys
/usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:600: warning:
method redefined; discarding old find_pair
/usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:607: warning:
method redefined; discarding old []=
/usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:611: warning:
method redefined; discarding old []
/usr/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/initializer.rb:615: warning:
method redefined; discarding old method_missing
rake backgroundrb:remove            # Remove backgroundrb from your
rails application
[snip]

unmerging rake, then installing rake via gem solves the problem:

cowboy current # emerge --unmerge rake
[snip]

cowboy current # gem install rake -r
Attempting remote installation of 'rake'
Successfully installed rake-0.7.1
Installing RDoc documentation for rake-0.7.1...
cowboy current # rake --tasks
(in /var/rails/rodeo/releases/20061005042627)
rake backgroundrb:remove            # Remove backgroundrb from your
rails application
[snip]

So something is different between the ebuild and manual gem installs...

Sorry, I didn't mean to take this thread into what belongs on bugzilla. 
I was more curious
on the philosophy on why duplicate the gems as ebuilds?  But I'm
thinking now it is probably
to allow gems to be dependencies of applications in portage.

Thank you,
Roy

-- 

echo "spzxAdjtdp/dpn" | perl -pe 's/(.)/chr(ord($1)-1)/ge'
-- 
gentoo-dev@gentoo.org mailing list



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2006-10-05 21:07 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-10-05 20:03 [gentoo-dev] ruby gems vs. ebuilds Roy Wright
2006-10-05 20:16 ` Boris Fersing
2006-10-05 21:03   ` Roy Wright

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox