On Mon, 2012-12-17 at 15:02 +0100, Diego Elio Pettenò wrote: > On 17/12/2012 14:49, Rich Freeman wrote: > > I'd also suggest at least considering how paludis handles this. They > > just have a directory containing config file per repository, with a > > priority setting. The portage tree is just another overlay, which is > > a good way to handle it. The sync mechanism handles the main tree > > identically to overlays as a result, though you can specify what to > > sync. > > Let's not conflate two completely different changes with two completely > different work required to deal with them. > > Changing our default locations, and the documentation is quick. Changing > the way the syncing/handling is done is a nightmare. > > If we conflate the issue, we can stop discussing as we're never ever > going to go anywhere. >
I agree. But for the purpose of answering Rich, layman is also capable of syncing the portage tree, although, not using the round robin and other user sync variations portage is capable of. Once I finish the python 3 compatibility code changes. I will re-visit getting layman's api use into portage, pkgcore for them to use to sync the overlays from within the package manager. I have already demonstrated how easy it is for portage to run layman's api. An in tree example is app-portage/esearch which adding the -l parameter will use the layman api if available or fall back to running layman in a subprocess to sync the overlays as well as the portage tree. -- Brian Dolbec <dol...@gentoo.org>
signature.asc
Description: This is a digitally signed message part
