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 <dolsen@gentoo.org>