Issue 63630 - Use Installable Package (.pkg) for Mac
Summary: Use Installable Package (.pkg) for Mac
Alias: None
Product: porting
Classification: Code
Component: MacOSX (show other issues)
Version: OOo 2.1
Hardware: Mac Mac OS X, all
: P3 Trivial (vote)
Target Milestone: OOo 2.3
Assignee: ericb
QA Contact: issues@porting
Keywords: aqua
Depends on:
Blocks: 11409
  Show dependency tree
Reported: 2006-03-25 21:21 UTC by moxfox
Modified: 2007-06-23 12:58 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

First try at creating Info.plist for the Installer (1.29 KB, text/plain)
2006-03-25 21:43 UTC, moxfox
no flags Details
First try at creating Description.plist for the Installer (384 bytes, text/plain)
2006-03-25 21:55 UTC, moxfox
no flags Details
prototype for a working pkg install (40.64 KB, application/x-gzip)
2006-03-26 18:52 UTC, moxfox
no flags Details
WIP - a checkpoint for installer work. Pre-requires issue 72835 (44.83 KB, patch)
2006-12-27 18:29 UTC, moxfox
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description moxfox 2006-03-25 21:21:51 UTC
While it is possible to use drag-and-drop install for also the X11 version of
the for Mac, it really should be an installable package.

The drag-n-drop is perfect for Aqua version, but OOo X11 needs X11 server and
other installation stuff (e.g. fondu fonts). Thus the concept of "drag and it's
immediately usable" is not fitting.

The .pkg installation scripts should check for X11 and not allow installing (or
help in installing X11) if X is not present.

There has been a .pkg version available before (OOo 1.x). Also, here is a nice
brief overview of the process:

There is probably a commandline version of the package manager to create the .pkg.
Comment 1 moxfox 2006-03-25 21:28:52 UTC
For more information:

man packagemaker
Comment 2 moxfox 2006-03-25 21:43:32 UTC
Created attachment 35251 [details]
First try at creating Info.plist for the Installer
Comment 3 moxfox 2006-03-25 21:55:34 UTC
Created attachment 35252 [details]
First try at creating Description.plist for the Installer
Comment 4 jjmckenzie 2006-03-26 03:30:35 UTC

Should this not be with 63030?

Comment 5 jjmckenzie 2006-03-26 03:47:28 UTC

Is this to replace the Info.plist file that already exists in the desktop module?

Comment 6 nospam4obr 2006-03-26 09:44:28 UTC

I see 63030 as a first step in this direction, as it will allow us to switch
between drag-and-drop & .pkg using configure.


are you aware of 11409 ? Because of the valuable information you added, I wonder
which of the issues to close as duplicate. I also wonder if should close 56189
as duplicate of 63030.
Comment 7 jjmckenzie 2006-03-26 14:35:34 UTC

What I see this issue is as 'issue-spread'.  All of the pertainent information
to solve an issue should be in one and only one issue.  The information provided
here is essential to solve the .pkg issue vice using .dmg.  Also, if there waa a
PRIOR issue, then that issue should be updated and the new issue marked as a
duplicate, not the other way round.  This is my opinion, and it is based on over
30 years of working with users.  If IZ 11409 still exists from the 1.1 days,
then I would consider that action as still valid and need of an update.

Comment 8 moxfox 2006-03-26 18:52:52 UTC
Created attachment 35269 [details]
prototype for a working pkg install
Comment 9 moxfox 2006-03-26 19:08:38 UTC
The package above contains the structure and test files for building a .pkg for
Mac X11. Eventually, it needs to be put inside a .dmg for transfer.

The readme and license files should be copied from OOo build (and renamed as
they are). The Welcome.html may be left out or created like that.

The scripts have been modified in following ways:
InstallationCheck -- check for Panther and X11
PostInstall       -- install fondu
ScriptTools.scpt  -- helper functions moved to this file
main.scpt         -- the script for With the fondu removed and using
helper functions.

It works, but there are bugs. use the to create the package. The
"Package_contents" -folder should contain Applications/<>/ and everything
in there. The permissions of those files needs to be changed appropriately. Make
"_build" -folder in the folder that the tar unpacked.
Comment 10 moxfox 2006-03-26 19:40:47 UTC
Apparently the installer scripts need to be shell scripts. So InstallationCheck
is going to change. The Postinstall, on the other hand, will probably just to a
shell script to load applescript...
Comment 11 jjmckenzie 2006-03-28 04:31:30 UTC

Was this packaging script from the work you did for IZ 63030 or is this
something else?

Comment 12 moxfox 2006-03-28 11:15:00 UTC
James: I have not done anything on 63030. This issues and issue 63030 are
related, but not overlapping.

This issue is somewhat overlapping with issue 57252, but I intend to separate
some of the stuff from here to issue 57252, when things get more mature.
Comment 13 jjmckenzie 2006-03-29 01:41:16 UTC

Is the patch in 63030 supposed to be here or with Issue 63030?  I think that
patch is supposed to build a .pkg.  This is why I'm confused with these two issues.

Comment 14 nospam4obr 2006-03-29 05:35:28 UTC
The patch in issue 63030 reworks the way the dnd installer is created, which is
- as far as I understand - what we want for the Aqua port and is also what I
think is back-portable to 2.0.2.

So the result of issue 63030 should be a in a .dmg, which
 no longer shows the wizard problem.
Comment 15 jjmckenzie 2006-03-29 15:42:38 UTC

Removed dependency on 63030 as that fixes the empty directory problem.


Are you working on the process to create an installer versus the .app (drag-n-
drop) process code?

Comment 16 jjmckenzie 2006-03-29 15:45:32 UTC

Removed dependency on 63030 as that fixes the empty directory problem.


Are you working on the process to create an installer versus the .app (drag-n-
drop) process code?

Comment 17 moxfox 2006-05-02 14:00:08 UTC
Even though I feel that this is very important issue for OOo X11 for Mac (after
macosxfondu is done), I won't unfortunately have time to work on this. I will be
going for a 2 month holiday starting May 22nd 2006, and there's just too much
stuff going on before that.

If nobody works on this during the late spring/summer, I'll start working on it
sometime in August....
Comment 18 moxfox 2006-09-05 08:12:23 UTC
With the AQUA -port getting so much attention and work, I'll also start working
in that area.

While I think that X11 would be better off with .pkg, I think for AQUA port just
having a .dmg (drag-n-drop) is quite ok. Of course, a .pkg for AQUA is equally
good alternative as well.
Comment 19 obrmac 2006-09-06 19:13:55 UTC
Actually there were some discussions lately about having, etc., which IMHO can only be 
solved in a clean way by placing the shared code (~ 90 %) somewhere in /Library/..

This will require some major tweaks of the installation structure though.
Comment 20 moxfox 2006-09-06 20:57:07 UTC
Ah, yes. That separate .app -thing is a nice idea. Especially if it would work
in a way that crashing/freezing writer app would not cause an open impress app
to crash too.

There is a well specified framework -mechanism in Mac OS X that makes building
such apps possible from the Mac -side of things. There are many open source
programs using it. One of those that I know is XULRunner (i.e. mozilla) which
will be used in Firefox 3.0 (and other mozilla apps, see the latest
trunk/nightly builds or CVS in Mozilla). The development builds leading to
Firefox 3.0 are called "Minefield". It's ok to look at their code, since it's
Comment 21 moxfox 2006-09-07 16:19:33 UTC
I created a wiki-page for the .app separation, at:
Comment 22 moxfox 2006-12-27 18:29:19 UTC
Created attachment 41725 [details]
WIP - a checkpoint for installer work. Pre-requires issue 72835
Comment 23 moxfox 2006-12-27 18:39:36 UTC
The patch above builds on the work in 72835, which moves and uses all
version-dependent files in instsetoo_native.

The patch uses pkg-installer uses Apple's native methods to build the package.
The installer files are correctly versioned and delivered to
instsetoo_native/unxmac*, but the actual installer script ( is not
launched yet.

The PostInstall.scpt is moved from inside the application to the installer. As
it should have always been.

The missing pieces are:
1) integration with instsetoo_native/util/
2) Additional X11 check in the beginning of installer, to prevent installing if
X11 is not present.

please have a look.
Comment 24 moxfox 2006-12-27 18:40:47 UTC
Comment 25 jjmckenzie 2007-02-05 03:45:09 UTC

Any updates to this issue?

James McKenzie
Comment 26 moxfox 2007-02-05 07:24:25 UTC
jjmckenzie: As you can see yourself, this issue depends on issue 73223, which is
fixed, but not integrated (cws macosxversioning01). So until that cws is
integrated, nothing will happen here.
Comment 27 moxfox 2007-05-24 21:13:25 UTC
cws macosxversioning01 is finally integrated... Since those CWSs seem to take
such a long time, I'm not so enthusiastic to speed this one up either.

I'm more interested in targetting aqua now, there are two things that would
really like this:
- the spotlight plugin (which itself is a .pkg), in cws spotlightplugin (not
- separate apps -patches, which require code that makes possible to have actual
runnable binaries for each application (the current shell scripts like "swriter"
are not enough).

Including spotlight within OOo install would actually mean creating a
metapackage (.mpkg) also, not just a package (.pkg).
Comment 28 moxfox 2007-05-24 21:15:11 UTC
Comment 29 shaunmcdonald131 2007-05-24 23:27:03 UTC
We don't need an installer, since we can copy the appropriate items on launch.
This is the way other applications do it, including Toast and EyeTV. Each launch
they make sure that any required components are in place, before completing the
the launch. 
This makes the application more versatile and less susceptible to users to doing
clean or archive and installs, where they keep or just drag the .app back into
their Applications folder. This means that the required components are not
available and the application will not launch properly.
If it is going to install things into restricted areas then the standard
authentication system for Mac OS X will need to be used to do the copy. It will
represent an increase in disk space required, though it will be more reliable
for the user.
Another option would be to symlink from the /Library/x folder to the specific
item in the applications folder.
Comment 30 moxfox 2007-05-25 07:28:33 UTC
1) dmg (drag-n-drop) is fine, when all you need to do is drag the application
icon to the application folder

2) pkg should be used for cases, where we are not simply operating on a
application icon, but we are also doing supportive installation actions, and/or
install files in multiple places

Spotlight plugin will need to be installed in /Library/... to guarantee it works
properly, as otherwise multiple instances of the same plugin can exist within
several OOo installs. That is big NO-NO according to Apple. Additionally, for
indexing to work properly, some shell commands need to be run during install.

Also, IMHO end users (developers maybe not) would benefit from profile migration
(or copying) during install, so that they don't have to worry about the details.
There was already discussion to still allow .dmg (disk image) builds for
developers with a configuration switch/environment variable.

With possible future "separate applications" work, we are not dealing with a
single application anymore, but several apps, which quite clearly changes the
concept too.

.pkg install allows us to show readme/license/any other text + errors (like
"cannot install on Jaguar") etc. to the user during _install time_, not during
runtime, which would make _every_ startup to go through a more complicated process.

All the "big" applications/suites use .pkg, for pretty obvious reasons. This
includes MS Office and iWork.
Comment 31 shaunmcdonald131 2007-05-25 08:57:07 UTC
> Also, IMHO end users (developers maybe not) would benefit from profile 
> migration (or copying) during install, so that they don't have to worry about 
> the details.
This will only work for the user who is installing ooo, it will not work in a
multi user environment where there are multiple users on the same machine. For
this to work in a multiuser environment, it needs to be done as part of the
first start wizard.

The first start wizard should be used for most of the other items that you
mention, including the copying of the spotlight plugin and running any
appropriate scripts.

I'll give 2 examples:
EyeTV uses its first start wizard to install a small background program into
/Library/Application Support/EyeTV/EyeTV and /Library/Application
Support/EyeTV/Wakein. A file is created for the storage of the channel tunings.
 This is done on every install so that these items are always installed and
available at launch. Using a .pkg can cause a problem, as this fix cannot be done.

An admin user is needed to do the first run.

For  Toast Titanium, there are items installed in the first run of Toast
Titanum, where you are given an option to install some optional items in certain
places. Again an admin user is required to do some of these installations, such
as a preference pane to /Library/PreferencePanes/ and ~/Library/Contextual Menu

I believe that ooo is a big enough application to allow for a change in the
installation behaviour. With the multiple applications the user will drag a
folder containing several applications and possibly a support folder, which
could be hidden.
Also the ability for the application to repair its self is very useful to users.
I personally have been caught out by Apple's iLife installers after an archive
and install of Mac OS X. Other applications, which fix themselves, were no
problem whatsoever, other than maybe a first run wizard showing up.

> .pkg install allows us to show readme/license/any other text + errors (like
> "cannot install on Jaguar") etc. to the user during _install time_, not during
> runtime, which would make _every_ startup to go through a more complicated 
> process.

You also want to have errors like, cannot run on system X due to problem Y on
start up, rather than on installation, as someone could be running ooo through
some old install, remotely, through a backup or through FireWire disk target
startup mode.
Comment 32 moxfox 2007-05-25 10:07:07 UTC
Well, obviously user can always break his install if he really wants to. Trying
to catch all the cases (e.g. user copying installed OOo (originally from .pkg
install) to another machine) is just not rational.

My proposal with .pkg/.mpkg results in relatively small amount of lines in the
actual code. I have already mostly working code, that exists. It heavily uses
existing Apple functionality that provides the necessary UI and task flow, and
thus is familiar from other application installs (and btw, .pkg install supports
asking for admin password if required).

What you are proposing is completely custom stuff, either by creating some Apple
native UI from scratch, or by heavily extending the OOo's first start wizard.

By wanting such a big change, you are actually volunteering to make that happen.
If for some reason you are not able to produce, let's say within next half year,
then I recommend that we use the .pkg -approach in the meantime.

After all, getting the real stuff to the hands of end users is what counts. Not
some fancy ideas floating in the air.

Comment 33 ismaelooo 2007-05-25 13:00:22 UTC
I agree with Shaun (smsm1), a dmg file to copy to the Application folder will be
easier for the user, the first start wizard doing stuff you propose for the .pkg
as this is the stuff the first start wizard is meant to do.

A .pkg file to install is more windows style and less easy to use for users. 

On Mac OS, users are used to doing a simple thing: drag and drop so let's doing
this (with .dmg). 

Comment 34 moxfox 2007-05-25 14:38:45 UTC
fine. Less work for me.
Comment 35 moxfox 2007-05-25 14:39:10 UTC
fine. Less work for me.
Comment 36 moxfox 2007-05-25 14:39:47 UTC
Comment 37 eric.bachard 2007-05-25 15:25:07 UTC
Hello all,

I know I arrive a bit late, but :

From my side, I was a pro- .pkg until Filip Molcan ( historically ) asked us to provide a .dmg.
Later, .pkg had a bug, building on Tiger ( or Panther, don't remember exactly)

What I propose :
I already booked a rendez-vous with the Apple UI Labs responsible during WWDC (exact date not yet 
defined, but that's ok ). 

FYI, I already met him last year, and I'll simply report his opinion. Then we could discuss with objective 
Comment 38 ismaelooo 2007-05-25 21:49:15 UTC
mox: I didn't say i wanted to do this task, i only agreed with Shaun's point of
view (providing a .dmg instead of a .pkg) so reassigning to macport.
Comment 39 pavel 2007-06-23 12:58:29 UTC