| 1 |
Dnia 2014-09-07, o godz. 21:03:00 |
| 2 |
Rich Freeman <rich0@g.o> napisał(a): |
| 3 |
|
| 4 |
> Right now the general policy is that we don't allow unmasked (hard or |
| 5 |
> via keywords) ebuilds in the tree if they use an scm to fetch their |
| 6 |
> sources. There are a bunch of reasons for this, and for the most part |
| 7 |
> they make sense. |
| 8 |
> |
| 9 |
> I was wondering if this policy still made sense in the case of scm |
| 10 |
> ebuilds that pull a particular git commit. While portage can't check |
| 11 |
> the Manifest, the fact is that git will in this case, and since we're |
| 12 |
> pointed at a content-hashed commit we can ensure that the package |
| 13 |
> never changes. We of course can't mirror it with the current setup |
| 14 |
> (there is no real reason we couldn't mirror git, but this is a |
| 15 |
> different problem). |
| 16 |
|
| 17 |
Just to be clear, we *can* mirror git. git-r3 has local git mirror |
| 18 |
support. |
| 19 |
|
| 20 |
> Tying ebuilds to a git commit has pros and cons, but I'm hard-pressed |
| 21 |
> to think of any actual QA issues. That is, something that would make |
| 22 |
> our tree inconsistent, or create a security vulnerability. |
| 23 |
> |
| 24 |
> Am I just not thinking of something? |
| 25 |
|
| 26 |
You're missing the big difference between a tarball and a git |
| 27 |
repository. |
| 28 |
|
| 29 |
Nothing about VCS fetching in Gentoo is standard. PMS covers only how |
| 30 |
to fetch files from SRC_URI and unpack them. It doesn't have any VCS |
| 31 |
support, and therefore our PMs don't have it. We hack it in using |
| 32 |
eclasses but it's pretty much 'best effort' policy. |
| 33 |
|
| 34 |
By default, git won't work offline. If you have a fetched tarball, |
| 35 |
portage will just check the checksum and say it's fine. Git will try |
| 36 |
fetching unless you manually tell it not to. Of course, this one could |
| 37 |
supposedly be improved but this actually may be undesired for security |
| 38 |
reasons. |
| 39 |
|
| 40 |
Then, git does fetching in src_unpack(). That's not the correct place |
| 41 |
to do so, and this means no kind of prefetching can handle it properly. |
| 42 |
Like 'connect, emerge --fetchonly, disconnect' -- and then build fails |
| 43 |
because git wants to fetch later. |
| 44 |
|
| 45 |
Furthermore, fetching via commit id is not supported by git. I mean it. |
| 46 |
You need to fetch via branch or tag. When you specify only a commit id, |
| 47 |
git-r3 only hopes it will be accessible via the branch specified |
| 48 |
(or the default one). And of course, this means fetching a lot more |
| 49 |
data than via snapshot tarball. |
| 50 |
|
| 51 |
Being a 'non-standard' file transfer protocol, git servers may be |
| 52 |
actually unreachable from restricted environments. Think of local |
| 53 |
network where Gentoo servers can access only a local distfile mirror. |
| 54 |
|
| 55 |
I think that's enough of enumerating. Some of the issues can be fixed |
| 56 |
but that's just git. If we support git like this, soon we will have |
| 57 |
requests for hg, bzr, svn, darcs and more... and we will be all 'to run |
| 58 |
Gentoo properly in restricted network, you have to set up 10 different |
| 59 |
local mirrors'... |
| 60 |
|
| 61 |
-- |
| 62 |
Best regards, |
| 63 |
Michał Górny |
Archives