On Jun 17, 2010, at 2:47 PM, Ryan Schmidt wrote:
> On Jun 17, 2010, at 16:22, Craig Hughes wrote:
>
>> Option 1: port mpkg/mdmg
>> ------------------------
>>
>> My package depends on a ton of stuff, which in turn depends on more, etc.
>> port mdmg produces a disk image which is about 400MB in size (including all
>> the shared libraries etc that the thing needs, plus all the docs etc for
>> those too). There seems to be some bug too where pango isn't packaged
>> correctly,
>
> Explain?
>
>> and Python2.6 just fails to install,
>
> 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.
The Python thing is this:
https://trac.macports.org/ticket/25174
>> so this is not currently working; I'm trying to tweak this to get it
>> working, but it looks like it's probably not gonna provide me a lot of
>> flexibility. One nice advantage is that folks don't need to have MacPorts
>> installed for this to work though, if it works. But if the *do* have
>> MacPorts installed, then actually it'll kind of mess stuff up, cos the pkg
>> will install stuff into /opt without telling ports about it, possibly nuking
>> stuff that ports actually installed there itself.
>
> 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
> 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.
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?
C
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
