Re: More on Install progress messages
Re: More on Install progress messages
- Subject: Re: More on Install progress messages
- From: Iceberg-Dev <email@hidden>
- Date: Sat, 25 Jul 2009 12:00:15 +0200
On Jul 25, 2009, at 1:33 AM, Kevin Brock wrote:
We were trying to change the install progress messages to something
a little more friendly.
We need a signed package, so using older versions of package maker,
or a non-flat format, wasn't really an option.
It looks like there's no way to modify the messages through the GUI.
1) The progress messages, "Installing xxx" are just using the name
of the package, xxx.pkg, in the flat package. 2) The name of the
package is derived from the actual item being installed. e.g, "Foo
Bar.app" becomes fooBar.pkg, and a file named com.mine.daemon.plist
becomes comminedaemon.pkg.
So, I used pkgutil to expand the package, renamed the actual
package files in the expansion directory, and then modified
Distribution to reflect the new package names.
Reflatten the package, sign and we're good to go, almost.
The problem is that this only works with install items which are
bundles. So Foo.app I can give a new pacakge name to, or Bar.kext,
but a daemon named somedaemon, which is being installed maybe in /
usr/sbin, can't be renamed. If I try to rename that package I get
an error from Installer when I try to install saying that there's
nothing to install in that package. This is true also if the
contents are a directory tree with only non-bundle items.
You also can't rename things to names which have spaces. I tried
doing this, using standard HTML space codes. #Foo Bar.pkg in
Distribution expanded correctly, and there was a package named "Foo
Bar.pkg", but Installer gave me the "nothing to install" error. It
*did* look for the correct package name, though. Just couldn't
process it.
So, I got part of what I needed. I'm astonished at the lack of
robustness and *extreme* lack of configurability in this stuff though.
If these things are doable in a standard way, then I'm even *more*
astonished at the lack of documentation. But then PackageMaker's
always been a little lacking in that area compared to other dev
tools...
I'm a bit surprised by the part related to the inability to rename a
package based on its payload. There should be no relation at all
between the payload and the name of the package.
Regarding the lack of support for spaces, apparently when you have a
package name with spaces, they are removed by PackageMaker.
If I were you, I would not go for one package for each component of
the application/solution. I don't see the point in doing this (and in
having implemented this in PackageMaker). Apple does not do that for
its own packages so I don't understand why they are enforcing this.
If your kext is updated, your application would probably be updated
to reflect at least the new minor version. If your daemon is updated,
idem.
With PackageMaker, it might be worth re-creating the branches of the
'/' hierarchy you need and then uses this fake '/' folder as the root
of your package payload.
My $0.02
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden