Re: [Buildroot] <PACKAGE>_SOURCE with <PACKAGE>_SITE_METHOD = git can result to tar.gz with mismatched file extension

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

Bagas, All,

On 2022-12-04 19:31 +0700, Bagas Sanjaya spake thusly:
> On 12/3/22 23:05, Yann E. MORIN wrote:
> >> I guess we have two options here:
> >>  (1) Detect this situation, and error out, to prevent this situation
> >>  from happening
> >>  (2) Actually support overriding _SOURCE, but in this case, we should
> >>  comply with the specified compression algorithm
[--SNIP--]
> > So, yes: detect and abort.
> Actually I think we can just do ``tar xvf`` since tar will automatically
> figure out the decompressor to use.

The issue is not so much about decompressing, than about compressing.

The download backends for VCS all expect to generate gzip-compressed
tarballs; see: support/download/git@231, support/download/svn@67,
support/download/cvs@70. For mercurial, it's even going deeper, as this
is ingrained in hg itself, and we rely on hg to generate the archive,
see support/download/hg@48..50 (it knows other compression formats, but
that may not align with the one we'd choose for the others).

The reason to request for a compression other than gzip is to achieve
one or more of:
  - decreasing the size of the generated archives;
  - decreasing the time needed to compress the archives;
  - decreasing the time needed to decompress the archives.

Aiming for those goals I believe only really makes sense globally, not
on a per-package basis.

If we were to go for a per-package support, we would need to convert all
our download backends anyway, and as I said previously, I don't think it
would be too cumbersome to migrate all the packages in one go at the
same time:
  - no cvs-hosted package;
  - a single svn-hosted package for which we have a hash: libxmlrpc (the
    other four have no hash);
  - two hg-hosted packages: dvb-apps, python-pygmes (the other three
    have no hash);
  - 112 git-hosted packages, so a bit more than 100 with a hash, and
    updating them can be easily scripted (that's what I did when we
    introduced the -br1 suffix for git).

Sure, we would also need to add that support to {go,cargo}-post-process,
but we do not have that many impacted packages either. However, for
those, I could well see a reason to have a per-package support, that we
shoved aside when introducing the download post-process: if we have to
download an unvendored archive that is not a tar.gz already, then we'd
have no way to represent that. But we assumed that all the packages that
would require vendoring would come from github or gitlab, they would all
be .tar.gz already, and that if we were to download a released archive,
it would already be vendored; this is turning to be actually the case
in practice: we only use archives from github/gitlab, so the point is
mostly academic.

So I still think we do not need support for different per-package
compression support, and that we shouldddetect the case that _SOURCE is
not set for a VCS-based download.

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