That exists. Add FEATURES="buildpkg" and everything you emerge will create a package in /usr/portage/packages
As for ready repositories. Everything in portage is ready to support this and I'm sure various specialized repositories are out there. Add PORTAGE_BINHOST="http://grp.mirror.site/gentoo/grp/1.4/i686/athlon-xp/"; to make.conf There is naturally also the following switched in emerge: --getbinpkg (-g) --getbinpkgonly (-G) --usepkg (-k) --usepkgonly (-K) On Thu, 6 Jan 2005 18:56:29 -0500, jose isaias cabrera <[EMAIL PROTECTED]> wrote: > > > Yes. For example, right now, somehow, my gcc is corrupted. I can't make > anything. So, it would be nice for me to do some > > emerge -binonly gcc > > command that would install a working gcc compiler and then I can go on and > build gcc again and take it from there. Now I have to rebuild my UltraSPAR > from scratch. Unless you know of another way... > > jos� > > > > ----- Original Message ----- > From: James Dio > To: [email protected] > Sent: Thursday, January 06, 2005 6:47 PM > Subject: Re: [gentoo-portage-dev] esearch > > Do you mean have Gentoo make packages as you emerge them or a repository > where there are already built packages for your disposal? > > Jim > > On Thu, 2005-01-06 at 14:51 -0500, jose isaias cabrera wrote: > > > > It would also be nice to emerge a full built package, like gcc, to a system. > My gcc is corrupted, so I have to wait until I build another server to fix > this one. It's a sad week for me. :-( > > > > ----- Original Message ----- > From: James Dio > To: [email protected] > Sent: Thursday, January 06, 2005 2:29 PM > Subject: Re: [gentoo-portage-dev] esearch > > > I like the idea of not having to have it tied into the sync directly but the > ability to do this would be cool. > > JIm > > On Thu, 2005-01-06 at 11:35 -0700, Dan Gregory wrote: > Having read all the esearch posts, it seems to me that what portage really > needs is a register/callback mechanism that would allow a package (such as > esearch) to register a callback with another package (such as rsync) that > gets executed when rsync is rerun/reinstalled/recompiled/etc. In this > example, you could just run the command to update the esearch database > whenever rsync is rerun. And this could be generically iimplemented so that > anyone that has a non-rebuild dependency on another package could use. This > solution keeps the nay-sayers happy by not tying esearch directly to rsync > and allows other variants of esearch (I don't know of any or I'd give > examples) to also be used, or if you don't care about speed searching you > don't install it and it works just like it does now. It also solves the what > database should we use question because you could have a different esearch > for each architecture. Dan Alec wrote: > Luke-Jr wrote: > >> On Sunday 02 > January 2005 5:52 pm, Ciaran McCreesh wrote: >> >> >>> On Sun, 2 Jan 2005 > 17:46:59 +0000 Luke-Jr <[EMAIL PROTECTED]> wrote: >>> | On Sunday 02 > January 2005 5:33 pm, Ciaran McCreesh wrote: >>> | > On Sun, 2 Jan 2005 > 17:24:34 +0000 Luke-Jr <[EMAIL PROTECTED]> >>> | > >>> | > wrote: >>> | > > | On Sunday 02 January 2005 4:26 pm, Fabian Zeindl wrote: >>> | > | > Will > esearch be included in emerge some time? >>> | > | >>> | > | A slightly > better question: Will an esearch database ever be >>> | > | included w/ > portage syncs like metadata is? I've got my private >>> | > | rsync > distributing it and it works quite well. >>> | > >>> | > Why? If you want to > distribute an esearch db, do it separately from >>> | > sync. It's a whole > different kettle of fish. Stick it on the web >>> | > somewhere... >>> | >>> > | How so? The database is directly based on the portage tree. Keeping >>> | > them together makes sense. >>> >>> But it has nothing to do with portage. > It's an entirely different >>> project which happens to use the portage > tree. Are you suggesting that >>> we distribute data for every single > package which happens to use the >>> portage tree in an emerge sync? >>> >> > >> >> If it doesn't take much room overall... why not? >> I'm not aware of > any besides esearch, though. And you can't say it has >> nothing to do with > portage when it is solely a portage tool. That's >> like saying gentoolkit > has nothing to do with portage... >> >> > It's not an Official portage tool. > Gentoo doesn't maintain it, so > why should they pay for the bandwidth to > distribute the metadata with > it? Especially when you can just run a > cronjob to update the metadata > for yourself? > -- > [EMAIL PROTECTED] mailing list -- [EMAIL PROTECTED] mailing list
