Q5: Freeform input about distribution of the Portage tree
(question-type: text)
(17 responses)

A:
"Nearly six months have passed since the CVS -> git migration, and the quality of rsync distribution has never really recovered.  It seems like this should have been higher priority, but I am hopeful that some day soon the users will have uncompromised ability to sync again, free from Manifest issues and upside down ChangeLogs."

A:
"While I do like and miss the old changelogs, newest first. I am slowly adapting to gathering that info via the git tree and git log.  It should also be possible to adapt the Changelog view to a git based tree and parsing git log output for a pkg path.

So I am open to all the possibilities."

A:
"I have heared of people using 'git clone --depth 1' because it is faster then rsync and has no local history. Wouldn't that be an option for use with the read-only git repo to further save space?"

A:
"The portage tree really needs strong cryptographic integrity protection and verification (e.g. GLEP 58)"

A:
"as an alternative to a repo with packages+all metadata, I would quite like to have a repo of only metadata/.

I want to use the dev portage tree and use a submodule for the metadata/ stuff so I get the md5-cache and the rest

git submodule add -b master anongit.g.o/gentoo-metadata.git
will add the submodule and make it track the branch.

then we can teach emerge --sync to run:
git submodule update --remote


https://stackoverflow.com/questions/9189575/git-submodule-tracking-latest/9189815#9189815"

A:
"I miss Date of first creation or author 
info in ebuild..at times..like the simplicity oF current sync process
"

A:
"I use snapshots exclusively, and consider changelogs essential."

A:
"I've always been a fan of not fixing things that aren't broken"

A:
"I would prefer that rsync does _not_  go away, git is more setup, and has some limitations that rsync does not. With rsync it is possible to only sync specific portions of the tree, and exclude certain paths etc. With git, it is basically the whole tree or nothing."

A:
"Don't call it the portage tree, call it the Gentoo repo or Gentoo tree, other than that, as long as the option is simple and reliable, I don't care too much about anything else."

A:
"No complaints. A developer-focused guide on using gentoo.git as /usr/portage would be great. The best we have presently is hasufell's repo. It's good, but something more official would be even better. If that's not a preferred approach, suggestions for how developers should manage their copy of the tree and develop ebuilds would be useful. The more people we have using direct-from-Git, the faster we can iron out bugs."

A:
"Transfer size reduction: Let portage prefer rsync servers that support compression, or have separate DNS rotation for them"

A:
"squashfs instead of (or in addition to) tarballs"

A:
"If a git repo with metadata could be less CPU and bandwidth consuming than the existing rsync infrastructure (even if improved with optional ChangeLog removals and whatnot), perhaps it would be worth heading that way as the default advertised method eventually"

A:
"Leave rsync to the average user to sync fast with the latest state of the tree (without useless overhead for the user). Developers may use git with full tree history in separate directories. Changelogs are better readable online."

A:
"I personally use this: https://github.com/hasufell/portage-gentoo-git-config"