[Buildroot] [PATCH] core/download: remove support for special git refs

Carlos Santos casantos at datacom.ind.br
Thu Oct 27 10:43:25 UTC 2016


> From: "Thomas Petazzoni" <thomas.petazzoni at free-electrons.com>
> To: "Vivien Didelot" <vivien.didelot at savoirfairelinux.com>
> Cc: "Yann E. MORIN" <yann.morin.1998 at free.fr>, "Ricardo Martincoski" <ricardo.martincoski at datacom.ind.br>,
> buildroot at buildroot.org
> Sent: Thursday, October 27, 2016 5:10:27 AM
> Subject: Re: [Buildroot] [PATCH] core/download: remove support for special	git refs

> Hello,
> 
> On Wed, 26 Oct 2016 18:27:57 -0400, Vivien Didelot wrote:
> 
>> > So, just remove the support for such special refs altogether.
>> 
>> I don't see why it is hard to maintain. A Github pull request ref or a
>> Gerrit change ref, as well as a custom ref, are valid git references.
> 
> They are valid, but moving references, right? A little bit like a
> branch.
> 
> And we don't support using Git branches as the Git version. Indeed, if
> you do that, Buildroot will clone the Git repo once, tarball it in
> $(DL_DIR), and will never download it again, because the name of the
> branch doesn't change, so the name of the tarball doesn't change.
> 
> And we don't even try to solve this problem, because using a branch
> name as the <pkg>_VERSION is just plain wrong.

As far as I know nobody is asking Buildroot to support branch names in
<pkg>_VERSION.

>> That can totally end up in a customer defconfig.
> 
> And this is bogus, and precisely why we don't want to support such
> thing. Github pull request and Gerrit change references are moving, so
> a given Github pull request can one day contain a given version of the
> code, and the next day a different version of the code. Hence you're
> giving your customers something that is not reproducible. Not good.

I'm not sure about Github pull requests but Gerrit change-ids could not
be used in <pkg>_VERSION because they are not valid Git commit-ids.

Each patchset in a Gerrit change has a unique commmit-id, which is not
a moving reference. It be referred to ether by a SHA-1 or by an explicit
path like "refs/changes/70/24070/1". The later is ugly but still unique
and will be saved be saved as 

   $(DL_DIR)/<pkg>-refs_changes_70_24070_1.tar.gz

Carlos Santos (Casantos)
DATACOM, P&D


More information about the buildroot mailing list