Re: PackageMaker madness with relocation / Snow Leopard
Re: PackageMaker madness with relocation / Snow Leopard
- Subject: Re: PackageMaker madness with relocation / Snow Leopard
- From: Mario Emmenlauer <email@hidden>
- Date: Sat, 03 Oct 2009 17:17:50 +0200
I found the answer to my relocation problem in the archives, in a message
from May. I was not aware of the fix that removing TokenDefinitions.plist
helps against relocations.
That makes a total of 6 workarounds and patches required to be sure the
package doesn't accidentally relocate. Whow!
Cheers,
Mario
-------- Original Message --------
Subject: Re: "Allow Relocation" Bugs
Date: Wed, 6 May 2009 18:13:35 +1200
From: John Gee <email@hidden>
To: sandeep chaudhary <email@hidden>, email@hidden
References: <email@hidden>
On 01/05/2009, at 20:26 , sandeep chaudhary wrote:
> I am working on PackageMaker and build a installer which will
> install some applications to user specified location. I am using
> the command line utility to build and run the package from package
> maker. But i am facing a problem with this. When i open the .pmdoc
> file, i found the "relocatable" check box is checked every time. So
> i have to uncheck all checkboxes , save .pmdoc file and run command
> to build the package every time. I want to turned off all
> checkboxes by default when i open the .pmdoc file. So that there is
> no need to uncheck all check boxes manually and resave the .pmdoc
> file .How can i solve this problem.
Two possible work-arounds:
1) You may be able to get the setting to stick by using an absolute
path to the source root for the contents. Some of the PackageMaker 3
bugs related to settings in the UI being lost only occur when using a
relative path.
2) You may be able to override the behaviour after building the
installer. Bill Coderre posted some interesting suggestions last year
to work-around this problem. Unfortunately I failed to find his
original post, but here is a fragment of the perl I am currently using
for building installers. My recollection is that relocatable is
implemented in the generated package using IFPkgPathMappings. This
code runs after generating the package, to undo the effects of
"Allows relocation".
# Remove "Allows relocation" on application.
my $plainInfo = "$fullSandpitPath/$outputName/Contents/Info";
system "defaults", "delete", $plainInfo, "IFPkgPathMappings";
my $naughtyFile = "$fullSandpitPath/$outputName/Contents/
Resources/TokenDefinitions.plist";
system "rm", "-rf", $naughtyFile;
--
John Gee, ADInstruments
Programmers live in interesting times...
Mario Emmenlauer wrote:
So should I create a bugreport for that? Am I the first to encounter
this relocation error on Snow Leopard? We can't support Snow Leopard
unless this issue gets fixed :-(
Cheers,
Mario
Mario Emmenlauer wrote:
Lance Ogletree wrote:
What version of packagemaker are you using.
The xcode 3.2 release for SnowLeopard installs a version 3.04. Does
it behave in the same manner?
Sorry for leaving this out, I have tried all releases of PackageMaker
that came with XCode 3.1, 3.1.1, 3.1.2, 3.1.3 (on Leopard), and 3.2
(on Snow Leopard). All Packages used to behave the same on Leopard,
meaning I needed to remove 'IFPkgPathMappings' from the finished package
in order to avoid relocation. I have tried only the packages from
XCode 3.1.3 and 3.2 on Snow Leopard, they behave identical (i.e., on
Leopard they do not relocate after removing 'IFPkgPathMappings', on
Snow Leopard 10.6.0 and 10.6.1 they relocate my application).
Cheers,
Mario
On Sep 29, 2009, at 9:12 AM, Mario Emmenlauer wrote:
Hi,
we release software quarterly, and customers install new releases
side-by-side with old releases.
With PackageMaker 3.0 and Tiger / Leopard, we had to apply an ugly
workaround to PackageMaker to strip the relocation flag from the
created package, else it would overwrite previous installations.
Since the workaround is scriptable, we could live with that.
Now it turns out that Snow Leopard does relocate the package again,
overwriting previous installations in the Trashcan and other
arbitrary places. This is not what I want!
Removing 'IFPkgPathMappings' from the finished package does not
help anymore, neither does stripping '<mod>relocatable</mod>'
nor setting 'relocatable="false"'. For Leopard, it also helped
to set a unique 'Package Identifier' (we did this by adding the
version number, i.e. com.company.programXXX.pkg), which does not
resolve the issue for Snow Leopard. My last hope was setting a
unique bundle name in the program's Info.plist, which leads to
a unique 'bundle id' in distribution.dist:
distribution.dist: <relocate search-id="pkmktoken2">
distribution.dist: <bundle id="com.company.programXXX"/>
distribution.dist: </relocate>
which did not help either. This is plain madness by now! Or
am I misunderstanding something? Please, please provide some
insight, or finally fix PackageMaker.
Cheers,
Mario Emmenlauer
Mario Emmenlauer wrote:
Hey Rick,
Rick Cochran wrote:
Here's what works for me:
sed -e '/<key>IFPkgPathMappings<\/key>/,/<\/dict>/d' -e
'/<key>IFPkgRelocatedPath<\/key>/,/<string>.\/<\/string>/d'
$(NAME).pkg/Contents/Info.plist > Info.plist.sed
mv Info.plist.sed $(NAME).pkg/Contents/Info.plist
It works perfectly! Thanks a lot!
BTW: Removing IFPkgPathMappings was sufficient, IFPkgRelocatedPath
does not appear in my package. Do you know if it is still needed
with mpkg from PackageMaker 3.0.3?
Best,
Mario Emmenlauer
-Rick
Mario Emmenlauer wrote:
Hi Bill,
I'm referencing an old message here, where you adress my exact
problem:
Bill Coderre wrote:
On Nov 22, 2008, at 10:23 AM, Adil Saleem wrote:
Previously i was using Package Maker on Mac OS 10.4 without any
problems. Now, for the first time, i have to use the Package
Maker (ver 3.0.3) on Mac OS 10.5. I created a package that
installs the application in /Applications/MyApp folder. On
running the package, it creates the folder MyApp in
/Applications folder, but the folder is empty. The application
file does not get copied.
Any idea why this is happening ?
Very likely PackageMaker is turning on the relocation flag due
to a longstanding bug. Relocation means that the Installer tries
to find an existing copy of your app to update. Say, the one in
the source folder that your package is built out of.
About a month ago, I wrote a couple of emails explaining how to
override this flag -- ripping it out of the appropriate places
in the finished package.
I would very much like to get my hands on this specific email,
however I could not find it in the archives (maybe it was on a
different list? You post too frequent to be sure:-) ).
My problem is that I generate the PackageMaker configuration auto-
matically, and call PackageMaker with it. The relocatable flag is
then *always* turned on, no matter what I specify in the xml.
I tried PackageMaker versions 3.0.0 - 3.0.3 to no success.
Can you tell me how to rip out the relocatable flag from either the
xml before running PackageMaker, or from the final mpkg package?
Best,
Mario
_______________________________________________
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
--
Dipl. Inf. Mario Emmenlauer Cell: +49-(0)176-23463809
Bitplane AG Office: +41-(0)44-430-1106
Badenerstrasse 682 Fax: +41-(0)44-430-1101
CH-8048 Zürich mailto:mario * emmenlauer.de
Zürich http://www.marssoft.de / http://www.xuvtools.org
_______________________________________________
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
____________________________
Lance Ogletree
email@hidden
_______________________________________________
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