Binary package installation without Portfile

[Ryan Schmidt]

On Jun 17, 2010, at 17:03, Craig Hughes wrote:

> On Jun 17, 2010, at 2:47 PM, Ryan Schmidt wrote:
> 
>> On Jun 17, 2010, at 16:22, Craig Hughes wrote:
>> 
>>> There seems to be some bug too where pango isn't packaged correctly,
>> 
>> Explain?
> 
> Jun 17 10:04:02 MicMacBook Installer[27823]: PFPkg: No file found at path: /Volumes/trickplay-sdk-0.0.4/trickplay-sdk-0.0.4.mpkg/Contents/Packages/pango-1.24.5.pkg
> Jun 17 10:04:02 MicMacBook Installer[27823]: PFPackage::packageWithURL - can't instantiate package: /Volumes/trickplay-sdk-0.0.4/trickplay-sdk-0.0.4.mpkg/Contents/Packages/pango-1.24.5.pkg
> Jun 17 10:04:02 MicMacBook Installer[27823]: Couldn't locate pango-1.24.5.pkg, a subpackage of trickplay-sdk, ignoring
> Jun 17 10:04:03 MicMacBook Installer[27823]: Package Authoring Warning: trickplay-sdk-0.0.4.mpkg authorization level is NoAuthorization but was promoted to RootAuthorization for compatibility, ensure authorization level is sufficient to install.
> Jun 17 10:04:22 MicMacBook installd[27835]: PackageKit: ----- Begin install -----
> Jun 17 10:06:39 MicMacBook installd[27835]: PackageKit: Install Failed: (null)\nError Domain=NSCocoaErrorDomain Code=512 UserInfo=0x102ebec70 "“Python” couldn’t be moved to “Frameworks”." {\n    NSDestinationFilePath = "/var/folders/zz/zzzivhrRnAmviuee+++++++++++/-Tmp-/PKInstallSandbox-tmp/Root/System/Library/Frameworks/Python.framework";\n    NSFilePath = "/var/folders/zz/zzzivhrRnAmviuee+++++++++++/-Tmp-/PKInstallSandbox-tmp/Root/opt/local/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app";\n    NSUserStringVariant = Move;\n}
> Jun 17 10:06:40 MicMacBook Installer[27823]: Install failed: The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.
> Jun 17 10:06:40 MicMacBook Installer[27823]: Displaying 'Install Failed' UI.
> Jun 17 10:06:40 MicMacBook Installer[27823]: 'Install Failed' UI displayed message:'The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.'.
> 
> Opening the mpkg in PackageMaker shows that the pango.pkg sub-package is just completely borked.  No data, no contents.  Not sure why, but it just didn't get constructed properly.

I'm afraid I don't know off the top of my head. I haven't played with MacPorts' package-creation feature much. You could check if updating pango to 1.28.0 helps; I've been meaning to test that upgrade for awhile anyway. You could also file a ticket about this problem, but I probably can't look into it soon.


>> Yes, please do not distribute binary packages created with "port mdmg" which were created with the default MacPorts prefix. Instead, install MacPorts with a different prefix specific to your product (e.g. /usr/local/something), then build the mdmg there.
> 
> Ok, that makes sense.  But now I'll have 1.4-odd GB of support packages installed in 2 places if they do use MacPorts -- once in /opt and once in /usr/local/something

I suppose so.


>> To cut down the size, you could remove documentation files, other files you don't need, etc. from each of the ports. You could keep local copies of the ports with these changes perhaps though of course then you'll have to be in charge of incorporating changes we make to the portfiles later.
> 
> So you mean basically editing the various portfiles for these guys to not include the docs?  port rdeps trickplay-sdk | wc -l says there's 192 of them, including stuff like perl, python, gcc43 AND gcc44, gnome stuff....  Whether it's editing the portfiles, or tweaking the .pkg files after they're generated, either way that's gonna be pretty painful to maintain.

The "gcc43 AND gcc44" problem should have been solved by one of Joshua's commits today; everything should be using gcc44 now.


> I agree that I think the mdmg strategy makes the most sense: it's certainly the most drop-dead easy for end-users, and switching the prefix to somewhere else solves the break-someone's-macports problem.  But is there any clever solution to the 1.4GB-of-junk install problem?  I can live with that, but it seems like there ought to be some clever solution, to just install the binaries and config files, and not all the supporting cruft like docs.  Maybe a "minimal" or "runtimeonly" variant for all the various individual ports?

You can check if any of those ports have any such variants, but it wouldn't be a common practice for port maintainers to include such variants. MacPorts packaging policy is to provide ports which are as featureful as possible, generally, and that install their documentation files, and to avoid adding variants whose only purpose would be to save a little disk space, since disk space is considered to be cheap. I recognize that in your case now it does add up, however.