Issue 63630

For more information:

man packagemaker
/Developer/Applications/Utilities/PackageMaker.app/Contents/MacOS/PackageMaker
--help

Created attachment 35251 [details]
First try at creating Info.plist for the Installer

Created attachment 35252 [details]
First try at creating Description.plist for the Installer

Mox:

Should this not be with 63030?

James

Mox:

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

James

James:

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

Mox:

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.

Oliver:

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.

James

Created attachment 35269 [details]
prototype for a working pkg install

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 OOo.app... With the fondu removed and using
helper functions.

It works, but there are bugs. use the makepackage.sh to create the package. The
"Package_contents" -folder should contain Applications/<OO.app>/ and everything
in there. The permissions of those files needs to be changed appropriately. Make
"_build" -folder in the folder that the tar unpacked.

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...

Mox:

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

James

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.

Mox/Oliver:

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.

James

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 OpenOffice.org 2.0.app in a .dmg, which
 no longer shows the wizard problem.

obr:

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

mox:

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

James

obr:

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

mox:

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

James

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....

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.

Actually there were some discussions lately about having writer.app, calc.app 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.

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
MPL/LGPL/GPL.

I created a wiki-page for the .app separation, at:
http://wiki.services.openoffice.org/wiki/Mac_OS_X_Porting_-_Separate_apps_%28OOoRunner_-framework%29

Created attachment 41725 [details]
WIP - a checkpoint for installer work. Pre-requires issue 72835

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 (create_pkg.sh) 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/makefile.mk
2) Additional X11 check in the beginning of installer, to prevent installing if
X11 is not present.

please have a look.

.

@mox

Any updates to this issue?

James McKenzie

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.

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
integrated)
- 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).

.

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.

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.

> 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 Helper.app 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
Items/

-
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.

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.

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). 

fine. Less work for me.

fine. Less work for me.

.

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 
informations.

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.

Closing.