On Mon, Jan 14, 2008 at 03:54:52PM -0500, John Baldwin wrote:
Also, if there are ports distfiles that unzip doesn't handle then there are
likely other zip files in the wild that users may run into that it won't
handle either. In that case, I think the ports distfiles are a good canary
for
Kris Kennaway [EMAIL PROTECTED] writes:
No, you'd have to duplicate the do-extract code (or add a special
variable for those 4 ports). I'd much rather wait to see what Tim and
Dag-Erling can come up with.
Take it easy everyone, no special-casing will be necessary as I fully
intend to add
The four files I've identified are:
Ah! Thanks for the list. Now that I'm back
from vacation, I've been meaning to ask you
for that.
Two of them are self-extracting. ... requires a few changes
in the API between the libarchive core and the support modules, which is
a published API ...
On Mon, Jan 14, 2008 at 02:35:07AM +0100, Kris Kennaway wrote:
Tim Kientzle wrote:
Of course, giving those four ports a build-time dependency
on the Info-Zip version is arguably the right approach
in any case.
That would probably be undesirable because it would mean having to
special case
David O'Brien wrote:
If we have to special case ports to deal with variant zipfiles that cannot
be processed by /usr/bin/unzip then it gets messier because we have to
account for some ports being satisfied with USE_ZIP=yes meaning
/usr/bin/unzip and some still requiring
On Monday 14 January 2008 03:26:03 pm Kris Kennaway wrote:
David O'Brien wrote:
If we have to special case ports to deal with variant zipfiles that
cannot
be processed by /usr/bin/unzip then it gets messier because we have to
account for some ports being satisfied with USE_ZIP=yes
On Mon, Jan 14, 2008, Kris Kennaway wrote:
David O'Brien wrote:
If we have to special case ports to deal with variant zipfiles that
cannot be processed by /usr/bin/unzip then it gets messier because we
have to account for some ports being satisfied with USE_ZIP=yes meaning
/usr/bin/unzip
David Schultz wrote:
On Mon, Jan 14, 2008, Kris Kennaway wrote:
David O'Brien wrote:
If we have to special case ports to deal with variant zipfiles that
cannot be processed by /usr/bin/unzip then it gets messier because we
have to account for some ports being satisfied with USE_ZIP=yes
Dag-Erling Smorgrav wrote:
Welcome unzip(1), ... can handle all but four of the 991 zip files (including
jar files) I was able to identify in the ports tree. The remaining four
are two self-extracting archives and two which have garbage preceding the
first local header. This
Tim Kientzle wrote:
Dag-Erling Smorgrav wrote:
Welcome unzip(1), ... can handle all but four of the 991 zip files
(including
jar files) I was able to identify in the ports tree. The remaining
four
are two self-extracting archives and two which have garbage
preceding the
first local
Of course, giving those four ports a build-time dependency
on the Info-Zip version is arguably the right approach
in any case.
That would probably be undesirable because it would mean having to
special case things in the ports tree and/or duplicate code.
I'm confused. How is it different
Tim Kientzle wrote:
Of course, giving those four ports a build-time dependency
on the Info-Zip version is arguably the right approach
in any case.
That would probably be undesirable because it would mean having to
special case things in the ports tree and/or duplicate code.
I'm confused.
des 2008-01-08 08:00:06 UTC
FreeBSD src repository
Added files:
usr.bin/unzipMakefile unzip.1 unzip.c
Log:
Welcome unzip(1), a pure BSD drop-in replacement for ports/unzip. In its
current state, it can handle all but four of the 991 zip files (including
jar
On Tue, Jan 08, 2008 at 08:00:06AM +, Dag-Erling Smorgrav wrote:
des 2008-01-08 08:00:06 UTC
FreeBSD src repository
Added files:
usr.bin/unzipMakefile unzip.1 unzip.c
Log:
Welcome unzip(1), a pure BSD drop-in replacement for ports/unzip. In its
Dag-Erling Smorgrav píše v út 08. 01. 2008 v 08:00 +:
des 2008-01-08 08:00:06 UTC
FreeBSD src repository
Added files:
usr.bin/unzipMakefile unzip.1 unzip.c
Log:
Welcome unzip(1), a pure BSD drop-in replacement for ports/unzip. In its
current state, it
Dag-Erling Smørgrav píše v út 08. 01. 2008 v 19:45 +0100:
Pav Lucistnik [EMAIL PROTECTED] writes:
BTW we are on track to commit a patch to the ports framework that will
make it use tar(1) for extracting .zip files.
You'll quickly find that it can't be done without changing a large
number
Pav Lucistnik [EMAIL PROTECTED] writes:
BTW we are on track to commit a patch to the ports framework that will
make it use tar(1) for extracting .zip files.
You'll quickly find that it can't be done without changing a large
number of ports. You'll also quickly find that there are zip files
Dag-Erling Smørgrav píše v út 08. 01. 2008 v 20:07 +0100:
Pav Lucistnik [EMAIL PROTECTED] writes:
BTW are you planning to do a __FreeBSD_version change for this unzip
import? So we have something to .if around in bsd.port.mk in future...
Not until libarchive has learned to handle those
Pav Lucistnik [EMAIL PROTECTED] writes:
BTW are you planning to do a __FreeBSD_version change for this unzip
import? So we have something to .if around in bsd.port.mk in future...
Not until libarchive has learned to handle those last four zipfiles.
There are other things that need to change as
19 matches
Mail list logo
