From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1MBYGm-0006rG-0H for garchives@archives.gentoo.org; Tue, 02 Jun 2009 17:59:28 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DF51EE03C2; Tue, 2 Jun 2009 17:59:26 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id C043CE03C2 for ; Tue, 2 Jun 2009 17:59:26 +0000 (UTC) Received: from [192.168.1.2] (graaff.xs4all.nl [80.101.101.38]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id C476D6579A for ; Tue, 2 Jun 2009 17:59:25 +0000 (UTC) Subject: Re: [gentoo-dev] Re: Files owned by multiple slots From: Hans de Graaff To: gentoo-dev@lists.gentoo.org In-Reply-To: References: <6EC3E6EE-F8BF-42F4-90F1-DEA00B628D09@delirium.ch> <1242215007.1403.2.camel@dhcp-16.lan.rep.sj> <4A0FFF35.3020408@gentoo.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-dHk3h8NJ6ohDSA/2FuMX" Organization: Gentoo Date: Tue, 02 Jun 2009 19:59:22 +0200 Message-Id: <1243965562.13426.6.camel@ip6-localhost> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 X-Archives-Salt: 92594b3a-44c3-4ae5-8eb9-56193c5a0955 X-Archives-Hash: a29481c9eda1cbe0e374a2a9f060bc19 --=-dHk3h8NJ6ohDSA/2FuMX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-06-02 at 17:43 +0000, Sven wrote: > (1) > All gems should be installed from ebuilds only. >=20 > (2) > If an ebuild requires a gem, it has to be installed from the correspondin= g > ebuild. For all other gems, Gentoo leaves the choice to the user and trie= s to > work together as well as possible with RubyGems. >=20 > Currently, reality is closer to (2) and I honestly don't believe it makes= much > sense to build the infrastructure to convert all gems to ebuilds automati= cally > and timely enough for (1) to come true. If the delay were only hours, Rub= y devs > would rather use the RubyGems manager than waiting for the ebuild to appe= ar. My personal preference is still to follow [1] as much as possible, because it allows me to handle all dependencies of a particular application within a single system. At work we have a private overlay which contains meta-ebuilds for our web applications, and I can use that to set up a blank server for one of our web apps with one emerge command, or update existing servers to new dependencies. On the other hand I also don't believe that we should provide all 1500+ gems as ebuilds, either through a manual or automatic process. Right now our rule of thumb is to add gems when they are popular (e.g. rails), when they provide an application that has been requested, or when they are needed as dependencies for either one of those. We also have a Summer of Code project to break down the monolithic default gem installation into Gentoo phases so that we can have more fine-grained control over the build, test, and installation process. Hans --=-dHk3h8NJ6ohDSA/2FuMX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkolaHoACgkQqj4ysMWt/vvE+ACfU9naQRGyjb09XqkFUP8o0mYV qx0AoLEPpBeIzdNw7+zOHID7fYIdpUkh =cQ4N -----END PGP SIGNATURE----- --=-dHk3h8NJ6ohDSA/2FuMX--