Re: EXTRACT_USING improvements: a concrete proposal

[Greg Troxel <gdt%lexort.com@localhost>]

Joerg Sonnenberger <joerg%bec.de@localhost> writes:

> On Thu, Mar 12, 2020 at 01:19:10PM -0400, Greg Troxel wrote:
>> We have had an objection (jperkin@) to adding "EXTRACT_USING=bsdtar" to
>> packages that have trouble with NetBSD's pax-as-tar, and I agree.  My
>> view is that a system should be using an extract tool that works with
>> what seems to be normal.  NetBSD now has one, even <=8, so this
>> workaround is no longer necessary.
>
> I can understand the position of Jonathan, but I also think it goes
> somewhat in the wrong direction. The reality is that quite a few
> platforms may or may not have a working modern tar implementation.

I guess it would be good to understand if that's true.  My take now is
that

  many platforms have GNU tar, and are already using it, by using
  "nbtar" and TOOL_PLATFORM.tar pointing to gtar

  NetBSD now uses bsdtar, compiled from pkgsrc on older versions

  There are a bunch of platforms that I suspect no one is paying much
  attention to

So I would suggest that the default EXTRACT tool has to be "working
modern tar", and that if a platform doesn't have that, it should set
EXTRACT_USING?=bsdtar in platform/Foo.mk, and then it will be ok.

Basically, I think it's much better to require a platform to have a
working tar than to try to accomodate deficient tars in individual
packages.

Do you see any problem with the

  if a platform's tar is (generally) not good enough, set EXTRACT_USING
  to bsdtar for that platform

approach?

>> So I'm going to remove the bsdtar workarounds for py-sphinxcontrib-*.
>
> ...so this is potentially a step backwards. It certainly shouldn't be
> done before going over all platforms and/or ensuring at least that the
> default extraction tool is a (new enough) GNU tar or BSD tar.

I did remove those four.  One of them, that I added, was conditionalized
on NetBSD, and I think consensus was that the other 3 should have been.
And all of these were newly added.

I will refrain from any further such changes for now.



Of course, we may find a bizarre distfile that only works with one
implementation, but I see that as accomodating a buggy distfile.  The
real test is "can we file a bug with upstream that their distfile is
broken" and it seems that with the sphinx stuff the answer is clearly
no.