1 |
Right now the general policy is that we don't allow unmasked (hard or |
2 |
via keywords) ebuilds in the tree if they use an scm to fetch their |
3 |
sources. There are a bunch of reasons for this, and for the most part |
4 |
they make sense. |
5 |
|
6 |
I was wondering if this policy still made sense in the case of scm |
7 |
ebuilds that pull a particular git commit. While portage can't check |
8 |
the Manifest, the fact is that git will in this case, and since we're |
9 |
pointed at a content-hashed commit we can ensure that the package |
10 |
never changes. We of course can't mirror it with the current setup |
11 |
(there is no real reason we couldn't mirror git, but this is a |
12 |
different problem). |
13 |
|
14 |
Tying ebuilds to a git commit has pros and cons, but I'm hard-pressed |
15 |
to think of any actual QA issues. That is, something that would make |
16 |
our tree inconsistent, or create a security vulnerability. |
17 |
|
18 |
Am I just not thinking of something? It would probably be most useful |
19 |
for packages that track a backport branch or something along those |
20 |
lines - where upstream does not regularly update their tarballs so |
21 |
we're constant creating patchsets. In this case all we'd have to do |
22 |
is bump the commit ID in the ebuild. |
23 |
|
24 |
-- |
25 |
Rich |