Bug 11567

Summary:	Idea for emerge option to web instead of local portage tree for speed
Product:	Portage Development	Reporter:	Matt Smith <slipmode>
Component:	Core	Assignee:	Portage team <dev-portage>
Status:	RESOLVED WONTFIX
Severity:	minor	CC:	bash83, ebnf, valkor
Priority:	High
Version:	2.0
Hardware:	x86
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---
Bug Depends on:	11672
Bug Blocks:

Description Matt Smith 2002-12-04 04:43:42 UTC

I was wondering about a function in Portage and had an idead. I sopke with
seemant about it along with others. I wondered why you should have todo an rsync
before you get an app to make sure it is the most current version. There were
some pluses to the rsync because you can maintian your local portage tree as
well as make changes to the builds. There might be others I am not thinking of
because I am new to Portage. I was thinking that if you wanted to just grab a
new app and not have todo the rsync process that a option could be added to
emerge and it would just forward to the updated portage tree on the web and
start from there. Skipping the rsync process. The benefit is for the users that
just add a app and that is all they wanted at the moment with the ability to
haveing knowing it was the most up to date app in the portage tree online. Also
it might save a small amount of bandwidth on your servers because I think some
of the people would just do the emerge with the web portage tree for an app here
and there and not grab the whole list for thier needs. I am a portage newb and
this was just an idea. Let me know what you think.

Comment 1 ebnf 2002-12-27 12:35:37 UTC

Along those lines an `emerge --check-web-for-updates world` could query against
just your currently merged packages instead of the whole tree, and so on. Of
course this gets into problems when the new packages have new dependancies which
have updates as well.  A possible solution is to just loop until no new updates
from new dependancies are found, caveat is that this moves a higher load to the
users' own DB.  This holds big potential for bandwidth savings on both ends.

Comment 2 Marius Mauch (RETIRED) gentoo-dev

2004-01-12 04:25:13 UTC

*** Bug 17406 has been marked as a duplicate of this bug. ***

Comment 3 Marius Mauch (RETIRED) gentoo-dev

2004-05-22 20:19:03 UTC

*** Bug 51783 has been marked as a duplicate of this bug. ***

Comment 4 Brian Harring (RETIRED) gentoo-dev

2004-08-14 00:25:39 UTC

To actually implement basically a remote tree (querying, fetching, etc) would require a fair overhaul of portage.
This would be glep material, since it would entail addition of a new tree type.
If anyone is interested, take it up on the gentoo-dev mailing list, and reopen this bug.  As is, no code, nor proposals, nor high priority (for me at least) :)