Roman Gaufman wrote:
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:
I would suggest using these, especially if you have a few extra gigs
of space to store them. The alternative ( Gentoo Binary Distribution
Mirrors ) will probably not happen any time soon. There exist
Unofficial mirrors now, although I dont' know of any offhand. I would
say you could use GRP, but especially with stuff like gcc randomly
installing programs that don't have your USE flags built in leads to
problems down the road.
In short, use the above :P
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
--
Alec Warner
Spartasoft Secretary ( spartasoft.msu.edu )
Junior Computer Science
Michigan State University
[EMAIL PROTECTED]
--
[EMAIL PROTECTED] mailing list
