Dnia 2014-09-07, o godz. 21:03:00 Rich Freeman <ri...@gentoo.org> napisał(a):
> Right now the general policy is that we don't allow unmasked (hard or > via keywords) ebuilds in the tree if they use an scm to fetch their > sources. There are a bunch of reasons for this, and for the most part > they make sense. > > I was wondering if this policy still made sense in the case of scm > ebuilds that pull a particular git commit. While portage can't check > the Manifest, the fact is that git will in this case, and since we're > pointed at a content-hashed commit we can ensure that the package > never changes. We of course can't mirror it with the current setup > (there is no real reason we couldn't mirror git, but this is a > different problem). Just to be clear, we *can* mirror git. git-r3 has local git mirror support. > Tying ebuilds to a git commit has pros and cons, but I'm hard-pressed > to think of any actual QA issues. That is, something that would make > our tree inconsistent, or create a security vulnerability. > > Am I just not thinking of something? You're missing the big difference between a tarball and a git repository. Nothing about VCS fetching in Gentoo is standard. PMS covers only how to fetch files from SRC_URI and unpack them. It doesn't have any VCS support, and therefore our PMs don't have it. We hack it in using eclasses but it's pretty much 'best effort' policy. By default, git won't work offline. If you have a fetched tarball, portage will just check the checksum and say it's fine. Git will try fetching unless you manually tell it not to. Of course, this one could supposedly be improved but this actually may be undesired for security reasons. Then, git does fetching in src_unpack(). That's not the correct place to do so, and this means no kind of prefetching can handle it properly. Like 'connect, emerge --fetchonly, disconnect' -- and then build fails because git wants to fetch later. Furthermore, fetching via commit id is not supported by git. I mean it. You need to fetch via branch or tag. When you specify only a commit id, git-r3 only hopes it will be accessible via the branch specified (or the default one). And of course, this means fetching a lot more data than via snapshot tarball. Being a 'non-standard' file transfer protocol, git servers may be actually unreachable from restricted environments. Think of local network where Gentoo servers can access only a local distfile mirror. I think that's enough of enumerating. Some of the issues can be fixed but that's just git. If we support git like this, soon we will have requests for hg, bzr, svn, darcs and more... and we will be all 'to run Gentoo properly in restricted network, you have to set up 10 different local mirrors'... -- Best regards, Michał Górny
signature.asc
Description: PGP signature
