Mark Knecht posted on Fri, 08 Aug 2014 11:34:54 -0700 as excerpted: > On Thu, Aug 7, 2014 at 2:18 PM, Duncan <1i5t5.dun...@cox.net> wrote: >> Mark Knecht posted on Thu, 07 Aug 2014 11:16:23 -0700 as excerpted: >> >>> I don't see any evidence that emerge checked what it downloaded, but >>> maybe those checks are only done when I really build the code? >> >> Here's what happens. >> >> FEATURES=webrsync-gpg simply tells the webrsync stuff to gpg-verify the >> snapshot-tarball that webrsync downloads. Without that, it'd still >> download it the same, but it wouldn't verify the signature. This >> allows people who use the webrsync only because they're behind a >> firewall that wouldn't allow normal rsync, but who don't care about the >> gpg signing security stuff, to use the same tool as the people who >> actually use webrsync for the security aspect, regardless of whether >> they could use normal rsync or not. >> > And to clarify, I believe this step is responsible for putting into > place on a Gentoo machine much of what's in /usr/portage, most > specifically in the app categorization directories.
Yes. It's basically the entire $PORTDIR tree (/usr/portage/ by default), the app categories and ebuilds plus digest files and patches, eclasses, metadata, the profiles, the whole thing. That's what emerge sync would normally update (via rsync), and emerge-webrsync replaces the normal emerge sync with a tarball download, signature verify if FEATURES=webrsyncgpg, and tarball extraction to $PORTDIR (while normally /usr/portage/, my $PORTDIR is set to put it elsewhere). The only bits of $PORTDIR that wouldn't be included would be $DISTDIR (/usr/portage/distfiles/ by default, but again I have mine set to something else), as source files are downloaded and hash-verified against against the hash-digest stored in the digest files (which are part of the signed tarball), and $PKGDIR (/usr/portage/packages/ by default, but again, I've set the variable to put them elsewhere), since that's binpkgs that portage creates if you have FEATURES=buildpkg or FEATURES=buildsyspkg set. Additionally, anything else that you configure to be placed in $PORTDIR won't be in the tarball, as you've configured that for yourself. Here, I have layman's overlays under $PORTDIR as well (the storage setting in layman.conf, by default set to /var/lib/layman), with an appropriate rsync-exclude set so emerge sync doesn't clear them out when I sync. Were I to switch to webrsync I might have to do something different as I guess webrsync would clear them out. Which reminds me, in all the discussion so far we've not talked about overlays or layman. But since that is optional, it can be treated as a separate topic. Suffice it to say here that the webrsync discussion does /not/ cover overlays, etc, only the main gentoo tree. > In the old days the Gentoo Install Guide used to have us download the > portage snapshots for a location such as > > http://distfiles.gentoo.org/snapshots/ > > That's now been replaced by a call to emerge-webrsync so newbies might > not have that view. Good point. I had noticed that change in passing when I found and referenced the handbook webrsync stuff too, but didn't think it worth mentioning. But you're correct, without the perspective of what it replaced, newbies might miss the connection. > Additionally, even if we're downloading the snapshot > tarball it appears, at least on my system, it's deleted after it's > expanded/ Or at least it's not showing up in a locate command. Interesting. Deleting by default after extraction does make sense, however, since otherwise you'd have an ever-growing cache of mostly identical content with only incremental change, tho I imagine there's some sort of config option to turn it off, in case you don't want it deleted. Tho I don't use locate here and in fact don't even have it installed. I never found it particularly useful. But are you sure locate would show it anyway, given that locate only knows about what is indexed, and the indexing only runs periodically, once a day or week or some such? If it hasn't indexed files since you started doing the emerge-webrsync thing, it probably won't know anything about them, even if they are kept. (Actually, that was my problem with locate in the first place. My schedule is never regular enough to properly select a time when the computer will be on to do the indexing, yet I won't be using it for something else so it can do the indexing without bothering whatever else I'm doing. Additionally, since it only knows about what it has already indexed, I could never completely rely on it having indexed the file I was looking for anyway, so it was easier to simply forget about locate and to use other means to find files. So at some point, when I was doing an update and the locate/slocate/whatever package was set to update, since I had never actually used it in years, I just decided to unmerge it instead. That must have been years ago now, and I've never missed it...) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
