[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: EXTRACT_USING improvements: a concrete proposal
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
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
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
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
>> 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
Main Index |
Thread Index |