Re: [gentoo-dev] Re: Files owned by multiple slots

2009-06-02 Thread Hans de Graaff
On Tue, 2009-06-02 at 17:43 +, Sven wrote: > (1) > All gems should be installed from ebuilds only. > > (2) > If an ebuild requires a gem, it has to be installed from the corresponding > ebuild. For all other gems, Gentoo leaves the choice to the user and tries to > work together as well as po

[gentoo-dev] Re: Files owned by multiple slots

2009-06-02 Thread Sven
> This can also be accomplish by a shared dependency package so is there a > particular benefit for extending EAPI to support this? If you look at it from a Gentoo-only perspecitve, there's probably no benefit. But it would allow Gentoo to work together nicely with RubyGems. So (apart from feasab

Re: [gentoo-dev] Re: Files owned by multiple slots

2009-05-17 Thread Petteri Räty
Sven wrote: > Gilles Dartiguelongue gentoo.org> writes: so this wrapper could be installed in a separate eselect sort of package ? >>> How exactly can this be done? If a gem creates five executables, would >>> this mean that this gem comes in six ebuilds? >> well given the next answer,

[gentoo-dev] Re: Files owned by multiple slots

2009-05-15 Thread Duncan
Sven posted loom.20090514t182756-...@post.gmane.org, excerpted below, on Thu, 14 May 2009 18:34:29 +: > Duncan <1i5t5.duncan cox.net> writes: >> FWIW, that'd not be a portage issue per se, but an EAPI issue, since it > > I see, very interesting! Sounds like a lengthy process, but never min

Re: [gentoo-dev] Re: Files owned by multiple slots

2009-05-14 Thread Ciaran McCreesh
On Thu, 14 May 2009 18:34:29 + (UTC) Sven wrote: > Duncan <1i5t5.duncan cox.net> writes: > > FWIW, that'd not be a portage issue per se, but an EAPI issue, > > since it > > I see, very interesting! Sounds like a lengthy process, but never > mind. Do you know where EAPI changes are discussed?

[gentoo-dev] Re: Files owned by multiple slots

2009-05-14 Thread Sven
Duncan <1i5t5.duncan cox.net> writes: > FWIW, that'd not be a portage issue per se, but an EAPI issue, since it I see, very interesting! Sounds like a lengthy process, but never mind. Do you know where EAPI changes are discussed? (Google and the Bugtracker didn't yield a useful reply.) Cheers, -

[gentoo-dev] Re: Files owned by multiple slots

2009-05-13 Thread Duncan
Sven posted loom.20090513t143352-...@post.gmane.org, excerpted below, on Wed, 13 May 2009 14:34:20 +: > Yet meanwhile I'd love to get some feedback on my original proposition: > Is it feasable and acceptable to expand Portage by the possibility to > declare a file shared between slots and on

[gentoo-dev] Re: Files owned by multiple slots

2009-05-13 Thread Sven
Gilles Dartiguelongue gentoo.org> writes: > > > so this wrapper could be installed in a separate eselect sort of > > > package ? > > How exactly can this be done? If a gem creates five executables, would > > this mean that this gem comes in six ebuilds? > > well given the next answer, it sounds

Re: [gentoo-dev] Re: Files owned by multiple slots

2009-05-13 Thread Gilles Dartiguelongue
Le mardi 12 mai 2009 à 22:55 +0200, Sven Schwyn a écrit : > Gilles wrote: > > so this wrapper could be installed in a separate eselect sort of > > package ? > How exactly can this be done? If a gem creates five executables, would > this mean that this gem comes in six ebuilds? well given the nex

[gentoo-dev] Re: Files owned by multiple slots

2009-05-12 Thread Sven Schwyn
Gilles wrote: so this wrapper could be installed in a separate eselect sort of package ? How exactly can this be done? If a gem creates five executables, would this mean that this gem comes in six ebuilds? If those kind of wrappers are generic enough, it could even be a single eselect package

[gentoo-dev] Re: Files owned by multiple slots

2009-05-11 Thread Sven Schwyn
Marijn wrote: Is it feasable to extend Portage to allow a file to be owned by several slots and remove it only once the last slot is uninstalled (aka: once the ebuild is completely uninstalled)? Do we have any guarantees that the file you want to share will be compatible with all gems that