On Tue, Sep 9, 2014 at 2:16 PM, Michał Górny <mgo...@gentoo.org> wrote: > Dnia 2014-09-09, o godz. 17:58:17 > hasufell <hasuf...@gentoo.org> napisał(a): > >> Michał Górny: >> > Dnia 2014-09-09, o godz. 17:41:27 >> > hasufell <hasuf...@gentoo.org> napisał(a): >> > >> >> Samuli Suominen: >> >>> >> >>> On 08/09/14 06:47, Rick "Zero_Chaos" Farina wrote: >> >>>> On 09/07/2014 09:03 PM, Rich Freeman wrote: >> >>>>> 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. >> >>>> Hard masking is a relic from the days that we didn't just have empty >> >>>> keywords, most of the VCS ebuilds in the tree just have empty keywords >> >>>> now and are not actually hard masked. I'd say if you set >> >>>> ACCEPT_KEYWORDS="**" then you get to keep the pieces. >> >>> >> >>> Hard masking is a relic? That's nonsense >> >>> >> >>> It just always has been a decision left for the developer him or herself >> >>> if the masking needs a message or not (package.mask being the way >> >>> to mask package with a message, empty KEYWORDS the >> >>> way you don't need a message) >> >>> >> >> >> >> Empty KEYWORDS is actually sort of a hack and basically says "doesn't >> >> work on any architecture" which is certainly always wrong and hides >> >> information from the user. >> > >> > You are incorrect. Lack of keyword means 'hell if I know whether it >> > works', which is pretty much the problem with live builds. >> > >> > 'Does not work' is represented by minus-keyword, e.g. >> > KEYWORDS="~amd64 ~x86 -*". >> > >> >> Saying "I don't know any architecture it works on" is also certainly >> almost wrong, unless the developer pushes ebuilds to the tree he has >> never even tested on his own machine (or didn't even ask upstream which >> architectures are supported). > > And how can you test a VCS ebuild? You can't assume upstream will be > stuck on one commit.
Well, my original question was regarding ebuilds pinned to a single commit. You can test that just fine. I will agree with Ulm that you lose the benefits of the mirror network (nothing prevents us from mirroring git, but certainly that doesn't happen today), and SHA1 might someday be vulnerable to a hash collision attack. However, barring an attack on SHA1 if I pin an ebuild to a git commit and test it, I can guarantee that it hasn't changed since it was tested. -- Rich
