1 |
On Tue, Sep 9, 2014 at 2:16 PM, Michał Górny <mgorny@g.o> wrote: |
2 |
> Dnia 2014-09-09, o godz. 17:58:17 |
3 |
> hasufell <hasufell@g.o> napisał(a): |
4 |
> |
5 |
>> Michał Górny: |
6 |
>> > Dnia 2014-09-09, o godz. 17:41:27 |
7 |
>> > hasufell <hasufell@g.o> napisał(a): |
8 |
>> > |
9 |
>> >> Samuli Suominen: |
10 |
>> >>> |
11 |
>> >>> On 08/09/14 06:47, Rick "Zero_Chaos" Farina wrote: |
12 |
>> >>>> On 09/07/2014 09:03 PM, Rich Freeman wrote: |
13 |
>> >>>>> Right now the general policy is that we don't allow unmasked (hard or |
14 |
>> >>>>> via keywords) ebuilds in the tree if they use an scm to fetch their |
15 |
>> >>>>> sources. There are a bunch of reasons for this, and for the most part |
16 |
>> >>>>> they make sense. |
17 |
>> >>>> Hard masking is a relic from the days that we didn't just have empty |
18 |
>> >>>> keywords, most of the VCS ebuilds in the tree just have empty keywords |
19 |
>> >>>> now and are not actually hard masked. I'd say if you set |
20 |
>> >>>> ACCEPT_KEYWORDS="**" then you get to keep the pieces. |
21 |
>> >>> |
22 |
>> >>> Hard masking is a relic? That's nonsense |
23 |
>> >>> |
24 |
>> >>> It just always has been a decision left for the developer him or herself |
25 |
>> >>> if the masking needs a message or not (package.mask being the way |
26 |
>> >>> to mask package with a message, empty KEYWORDS the |
27 |
>> >>> way you don't need a message) |
28 |
>> >>> |
29 |
>> >> |
30 |
>> >> Empty KEYWORDS is actually sort of a hack and basically says "doesn't |
31 |
>> >> work on any architecture" which is certainly always wrong and hides |
32 |
>> >> information from the user. |
33 |
>> > |
34 |
>> > You are incorrect. Lack of keyword means 'hell if I know whether it |
35 |
>> > works', which is pretty much the problem with live builds. |
36 |
>> > |
37 |
>> > 'Does not work' is represented by minus-keyword, e.g. |
38 |
>> > KEYWORDS="~amd64 ~x86 -*". |
39 |
>> > |
40 |
>> |
41 |
>> Saying "I don't know any architecture it works on" is also certainly |
42 |
>> almost wrong, unless the developer pushes ebuilds to the tree he has |
43 |
>> never even tested on his own machine (or didn't even ask upstream which |
44 |
>> architectures are supported). |
45 |
> |
46 |
> And how can you test a VCS ebuild? You can't assume upstream will be |
47 |
> stuck on one commit. |
48 |
|
49 |
Well, my original question was regarding ebuilds pinned to a single |
50 |
commit. You can test that just fine. |
51 |
|
52 |
I will agree with Ulm that you lose the benefits of the mirror network |
53 |
(nothing prevents us from mirroring git, but certainly that doesn't |
54 |
happen today), and SHA1 might someday be vulnerable to a hash |
55 |
collision attack. |
56 |
|
57 |
However, barring an attack on SHA1 if I pin an ebuild to a git commit |
58 |
and test it, I can guarantee that it hasn't changed since it was |
59 |
tested. |
60 |
|
61 |
-- |
62 |
Rich |