Re: [Buildroot] [PATCH 5/5] support/download/git: handle git attributes

["Yann E. MORIN" <yann.morin.1998@free.fr>]

Arnout, All,

On 2023-09-17 19:52 +0200, Arnout Vandecappelle spake thusly:
> On 15/09/2023 09:50, Yann E. MORIN wrote:
> >On 2023-09-14 23:07 +0200, Thomas Petazzoni spake thusly:
> >>On Wed, 13 Sep 2023 00:15:52 +0200
> >>"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
> >[--SNIP--]
> >>>Extend the git backend to handle the export-subst attribute. There is
> >>>no git tool (that we could find) that does that automatically, except
> >>>git-archive, which we can't use. So, we do it manually with a bit of
> >>>trickery where we do use awk to:
> >>>   - identify all files that have the export-subst attribute set,
> >>>   - for each such file, iterate over all the placeholders, and
> >>>     replace them with the expanded format.
> >[--SNIP--]
> >>I am not totally convinced by this. I recognize the massive efforts
> >>that have been into these complex awk scripts, but there are a few
> >>reasons why I dislike it:
> >>(1) It's complex/non-obvious
> >TBH, we've seen more complex code (awk or otherwise) get in. ;-)
> >But I do agree that we need to asses the complexity vs. gain ratio.
>  I haven't looked at it in a lot of detail, but it didn't look _that_
> complex to me.

I noticed a little coding-style issue in there (missing semi-column on
end of line, innocuous as it's optional, but that's diverging from the
rest of the file). I'll fix and respin a v2.

[--SNIP--]
> >For that second point, we have always had people that wanted to keep the
> >git tree because their build system wanted to extract the git hash (or
> >other info) so that they can quickly identify the source *on a running
> >target*. Telling those to use export-subst can be a solution (now, we
> >just need to convince Linus to add that to his kernel tree ;-) ).
>  It would be nice if we could generate a file that git-describe recognizes
> and uses instead of the actual git tree. Or perhaps we should create a git
> wrapper that does exactly that.

In retrospect, I was thinking about override-src-dir packages. For
those, we could look into something like:

    ifneq ($$($(2)_OVERRIDE_SRCDIR),)
    $(2)_ENV += GIT_DIR=$$($(2)_OVERRIDE_SRCDIR)/.git
    endif

> >Finally, we also bumped the subversion backend version, which is now
> >-br3; that will probably have caused a lot of churn for those numerous
> >companies that still use svn. I don't see why that would be acceptable
> >for one backend and not another.
>  I expect the impact of svn to be much smaller. Also, mistakes made in the
> past doesn't mean we should make the same mistake again :-)

Sure, but svn is in fact still quite widely used in $big_corps...

> >>Of course, I can be convinced that I'm wrong, but I'm not too convinced
> >>at the moment. And of course (again), Peter and Arnout are definitely
> >>welcome to disagree and overrule me :)
> >You won't be surprised when I tell you I believe it is worth it. ;-)
>  Yeah, I do think we should do everything we can to make sure the git
> archives are reproducible.

What we currently have is *already* reproducible, and I was not arguing
that was not the case. The point was about adding support for
export-subst, not reproducibility (but adding export-subst should also
be reproducible, hence the core.abbrev=40).

So, I'll fix the little coding style issue, add a section in the manual,
and resubmit, with a conversion of luajit while at it.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot