Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 351808 - Emerge Quick Sync
Summary: Emerge Quick Sync
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Conceptual/Abstract Ideas (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-15 22:17 UTC by Lie Ryan
Modified: 2011-01-16 08:33 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lie Ryan 2011-01-15 22:17:29 UTC
It would be nice if it is possible for "emerge --sync" only installed applications instead of the whole portage tree. 

What are the implications?

When changing USE flags such that there are new dependencies, emerge will first need to sync the new dependencies to the same state as the rest of the installed apps.

When emerge-ing new application, portage may not be able to find applications that have only been added to the tree since last full sync.
Comment 1 Zac Medico gentoo-dev 2011-01-15 22:27:35 UTC

*** This bug has been marked as a duplicate of bug 349719 ***
Comment 2 Lie Ryan 2011-01-16 00:01:58 UTC
Bug 349719 feature request is different from this feature request. That feature requests seeks for the ability to sync only ebuilds for a particular machine architecture, profile, and OS. This feature requrest seeks for the ability to sync only *currently installed* ebuilds.

The rationale is that there are only about 600-1200 ebuilds installed at any particular time in a typical Gentoo machine and generally only 10-20 are being updated at a time, while there are more than ~14000 ebuilds in the whole portage tree (excluding overlays). If this feature can be implemented, we only need to rsync about 600-1200 folders instead of all 14000 folders. 

The drawback is that at installation/updating time, portage will have to sync the ebuilds of *new* dependencies to bring them up-to-date with the ebuilds of currently installed apps. This might increase the time for dependency calculation slightly.

Another minor drawback is that doing any sort of searching may not always give the most up-to-date result, though you usually do not need the most up-to-date package names and descriptions and they do not change often; and even then, it is easily resolved by doing full sync from time to time. 

The obvious benefit is a faster sync and smaller data transfer. This might allow portage to sync and ready for emerge update in ~10-20 seconds, by my back of the envelope calculation.
Comment 3 Zac Medico gentoo-dev 2011-01-16 00:24:31 UTC
(In reply to comment #2)
> Bug 349719 feature request is different from this feature request. That feature
> requests seeks for the ability to sync only ebuilds for a particular machine
> architecture, profile, and OS. This feature requrest seeks for the ability to
> sync only *currently installed* ebuilds.

Neither approach seems practical to me. I'd suggest to fetch all of the dependency metadata, as mentioned in bug #349719, comment #2.
Comment 4 Lie Ryan 2011-01-16 08:18:35 UTC
Fetching dependency metadata is a different approach, but I think that will open cans of worms when emerging ebuilds that supports multiple DE/backends/GUI/drivers/etc since that would mean you have to maintain KDE ebuilds if you only uses Gnome (or vice versa) or you have to download ATI drivers if you only have nVidia drivers (or vice versa). Otherwise, if the ebuild metadata contains enough information for sync to select only the dependencies it needed, it will cause a sync to be at least just as long as an "emerge -p world"; the purpose of partial sync is to reduce sync time.
Comment 5 Zac Medico gentoo-dev 2011-01-16 08:33:11 UTC
The metadata that's needed for dependency calculations is pretty small, especially if compressed. I'm pretty sure that all other distros distribute all the dependency metadata in a single compressed bundle like this. It doesn't make sense to break it up into separate http requests when it's faster to download the whole thing as a single compressed bundle.