Closed Bug 8136 Opened 25 years ago Closed 22 years ago

libjar standalone API needs #ifdef MAC entry point

Categories

(Core Graveyard :: Installer: XPInstall Engine, defect, P4)

Product:
Core Graveyard
Component:
Installer: XPInstall Engine
Platform:
PowerPC
Mac System 8.5
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: cathleennscp, Assigned: slogan)

References

Details

(Keywords: platform-parity, Whiteboard: [nsbeta2-] [PDT-]) 

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.
Target Milestone: M8
set target milestone to M8
Summary: libjar needs a interface that accepts nsFileSpec → libjar needs a interface that accepts nsIFileSpec
Priority: P3 → P1
this bug is to get Mac libjar/zlib standalone working.  Needs to be in M8.
Set priority to P1
Priority: P1 → P3
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.
Status: NEW → ASSIGNED
Target Milestone: M8 → M9
moving to M9
Blocks: 11020
Summary: libjar needs a interface that accepts nsIFileSpec → [feature] libjar needs a interface that accepts nsIFileSpec
Target Milestone: M9 → M10
Moving to M10.
Assignee: sgehani → dougt
Status: ASSIGNED → NEW
Reassigning to Douglas per XPInstall mega-meeting.
Target Milestone: M10 → M15
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
Blocks: 18482
It accepts a PRFileDesc* which is just as good.  Closing as WONTFIX.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → 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.
Status: RESOLVED → REOPENED
Oops, I meant ZIP_OpenArchive(), not the extraction routine.
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.
Assignee: dougt → sgehani
Status: REOPENED → NEW
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.
Resolution: WONTFIX → ---
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
Status: NEW → ASSIGNED
Keywords: beta1
Target Milestone: M15 → M14
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.
Summary: [feature] libjar needs a interface that accepts nsIFileSpec → [feature] libjar standalone API needs #ifdef MAC entry point
Keywords: pp
OS: All → Mac System 8.5
Hardware: All → Macintosh
PDT-
Whiteboard: [PDT-]
Target Milestone: M14 → M16
Target Milestone: M16 → M17
samir, is this fixed?
we need libjar to extract xpi archive.
Keywords: nsbeta2
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.
Summary: [feature] libjar standalone API needs #ifdef MAC entry point → libjar standalone API needs #ifdef MAC entry point
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.
Whiteboard: [PDT-] → [nsbeta2-] [PDT-]
Priority: P3 → P4
Resetting target field for missed milestones
Target Milestone: M17 → ---
we've lived without it so far...
Keywords: beta1 → nsbeta1-
Keywords: nsbeta1-
Over to Syd for installer bug triage
Assignee: sgehani → syd
Status: ASSIGNED → NEW
Target Milestone: --- → M1
Target Milestone: M1 → Future
Does this bug still need to happen?
removing nsbeta1- for Buffy
removing nsbeta1-, Mac Installer for Buffy
removing nsbeta1- Mac bugs for Buffy
Keywords: nsbeta1-
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
Status: NEW → RESOLVED
Closed: 25 years ago → 22 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.