Samir, before you work on this bug, please talk to Dan about it. There are things you need to watch out for not breaking the standalone.

set target milestone to M8

this bug is to get Mac libjar/zlib standalone working. Needs to be in M8. Set priority to P1

Bug 8621 has been filed regarding the above issue: "Standalone libjar build on the Mac." We will continue to use this bug to track the libjar nsIFileSpec interface cross-platform issue. Bumping down priority per discussion with Cathleen and Sean.

moving to M9

Moving to M10.

Reassigning to Douglas per XPInstall mega-meeting.

since nsIFileSpec is going to be going away at some point, I would suggest using nsIFile. Postponing to after beta.

Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall Engine

It accepts a PRFileDesc* which is just as good. Closing as WONTFIX.

The problem is that the C API (ZIP_ExtractFile() in particular) accepts a filename string. This means libjar is broken for the Mac since we haveto pass in a string. The wizard needs this fix. Reopening.

Oops, I meant ZIP_OpenArchive(), not the extraction routine.

what is wrong with using: http://lxr.mozilla.org/seamonkey/source/modules/libjar/nsZipArchive.cpp#292

Standalone libjar exports the C API. Hence we need this bubbled to the C API. Anyways, never mind. Just reassign this back to me and I'll deal with it.

pong.

Clearing resolution. We should use the same #ifdef XP_MAC hack we used in xpistub to allow the Mac interface to pass a native Mac thingy.

Nominating for beta1 because without this there are three evil bugs: 1> can't have slashes in path name to installation 2> fails when user moves a dir during processing 3> fails to handle 2 volumes with the same name

This is fixed -- nsIZipReader accepts only an nsIFile, which opens the nsZipArchive with its file descriptor gotten in a magic Mac-safe way. For standalone use ZIP_OpenArchive() still uses a string, but it can't use an nsIFileSpec because it's *standalone*. Should this bug be re-summarized to "libjar standalone API needs #ifdef MAC entry point"? Then just do what we did with the XPIStub standalone interface. I agree, sounds like a beta1 problem.

Was tempted to change the summary anyways. Thanks.

PDT-

samir, is this fixed? we need libjar to extract xpi archive.

Cathleen, This is not fixed. Libjar does extract .xpis just fine. This bug is merely to change the dll entry point. I will work on it in M17 as scheduled. This is no longer a feature. This bug has morphed into a small chore. Removing "feature" designation from the summary.

Putting on [nsbeta2-] radar. Not critical to beta2. But let PDT know if you think this is a big impact to the user for PR2.

Resetting target field for missed milestones

we've lived without it so far...

Over to Syd for installer bug triage

Does this bug still need to happen?

removing nsbeta1- for Buffy

removing nsbeta1-, Mac Installer for Buffy

removing nsbeta1- Mac bugs for Buffy

Quoth Steve Dagley: "The Mac installer code was never Carbonized and there is no intention to ever change that." http://groups.google.com/groups?threadm=yahoo_com-77F6E8.09344011022003%40h-204-29-187-156.netscape.com http://groups.google.com/groups?threadm=avkj4k%24ihs2%40ripley.netscape.com