Re: MacPorts hosted mdmg
At 12:15 PM +0100 3/15/15, Marko Käning wrote: On 15 Mar 2015, at 00:02 , Bradley Giesbrecht wrote: ...Imagine you want to ship, say, one of these KDE games. They are nice and small, but need the whole background of KDE4/KF5 libs for them to function - of course. Instead of shipping KDE or KF5 as a whole with each and every little game, it would be very nice to have a means to redistributeably install a meta-port like kde4-workspace (as discussed in the before-mentioned parallel thread) which then would include everything needed for properly running any KDE4 application. One would then have to ship only the meta-port mdmv package and the several mdmg packages for the whatever KDE4 application. All these would - IDEALLY - have to be built in such a way that they can coexist with an existing MacPorts installation, I suppose. This does not only mean that the PREFIX shouldn't be /opt/local, but merely also that the application's configuration data needs to be put in location(s) separate from the standard ones used by a normal MacPorts install Think about /Library/Launch(Agents|Daemons) [~]/Library/Application Support ~/Library/Preferences/KDE ~/Library/Caches ~/.config ~/.(cache|config) and possibly quite a few others. Since this is even more complicated, for a start I think, one would surely like to avoid such a coinstallable approach. However, not having it would make testing pretty hard (if not even close to impossible), I am afraid. I don't think there is any realistic way to do 'additive' installers (ie install a bunch of base libraries with one installer and then install one or more apps that use those libraries). I think it would be all too common for the user to install the base and one app at one time and then, months or years later, install another app only to find that it is broken due to base upgrades in between. Another wrinkle that occurred to me is that mdmg installers sometimes need to be built with non-default variants. For example, my standard invocation for Myth is: sudo port -f mpkg mythtv-pkg.27 +mariadb+mariadb55+python27+perl5_16+startupitem I _have_ to specify +mariadb+mariadb55+startupitem or the MythTV package will be non-functional. The +python27+perl5_16 ensures that I don't get copies of other versions of perl and python--thus reducing the size of the installer by about 20% (which is still ~400 MB). I have to use the -f flag to make the horrendous hack in MacPort_daemondo succeed. I'm hoping a GSOC student will figure out a clean fix for the issue. Craig ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts hosted mdmg
At 4:02 PM -0700 3/14/15, Bradley Giesbrecht wrote: On Mar 14, 2015, at 2:26 PM, Marko Käning wrote: ... Installing all these dependencies is only acceptable for techies like us, but a normal user will never bother to deal with all the hassle. I think we have an opportunity to extend what MacPorts does well to include relocatable packages or mdmg packages in a way that third parties can build distributable packages untethered from MacPorts and Xcode. Gimp, Kdenlive, digiKam, Octave and many KDE "things" would sing praises to MacPorts. I created mythtv-pkg.27 solely to facilitate creating an installer package. Currently, MacPorts makes it possible to do something that would otherwise be much more difficult. As Clemens pointed out, it would be really nice if post-activate actions were automatically converted to postflight scripts. Better handling of launchd stuff would also be nice. Neither of these things are show-stoppers, though. One just has to provide clear user instructions for the bits that have to be done manually. If we wanted to use the buildbots to assist with such packaging, I would think that we should add a directive to the appropriate portfiles that cause them to be packaged. Packaging individual libraries would be of no value. Packaging is valuable for those user-facing applications where upstream doesn't regularly produce dmg's. Right now, I use Parallels to maintain several OS X environments to test building and deploying my Myth package. Putting some of that load on the buildbots would be darn nice. Especially making installers for each major OS version. But I would still want to test on a virgin system before inflicting it on unsuspecting users. Craig ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts hosted mdmg
On 15 Mar 2015, at 12:15 , Marko Käning wrote: > /Library/Launch(Agents|Daemons) > [~]/Library/Application Support > ~/Library/Preferences/KDE > ~/Library/Caches > ~/.config > ~/.(cache|config) I meant to write: /Library/Launch(Agents|Daemons) [~]/Library/Application Support ~/Library/Preferences/KDE ~/Library/Caches ~/.(cache|config|local) =) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts hosted mdmg
Brad, On 15 Mar 2015, at 00:02 , Bradley Giesbrecht wrote: > I think we have an opportunity to extend what MacPorts does well to include > relocatable > packages or mdmg packages in a way that third parties can build distributable > packages > untethered from MacPorts and Xcode. Gimp, Kdenlive, digiKam, Octave and many > KDE “things" > would sing praises to MacPorts. I fully concur with you, but I guess that must be a major undertaking… Yet it would be really nice to have a feature like that! Imagine you want to ship, say, one of these KDE games. They are nice and small, but need the whole background of KDE4/KF5 libs for them to function - of course. Instead of shipping KDE or KF5 as a whole with each and every little game, it would be very nice to have a means to redistributeably install a meta-port like kde4-workspace (as discussed in the before-mentioned parallel thread) which then would include everything needed for properly running any KDE4 application. One would then have to ship only the meta-port mdmv package and the several mdmg packages for the whatever KDE4 application. All these would - IDEALLY - have to be built in such a way that they can coexist with an existing MacPorts installation, I suppose. This does not only mean that the PREFIX shouldn’t be /opt/local, but merely also that the application’s configuration data needs to be put in location(s) separate from the standard ones used by a normal MacPorts install… Think about /Library/Launch(Agents|Daemons) [~]/Library/Application Support ~/Library/Preferences/KDE ~/Library/Caches ~/.config ~/.(cache|config) and possibly quite a few others. Since this is even more complicated, for a start I think, one would surely like to avoid such a coinstallable approach. However, not having it would make testing pretty hard (if not even close to impossible), I am afraid. Greets, Marko signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts hosted mdmg
On Mar 14, 2015, at 2:26 PM, Marko Käning wrote: > Brad, > > On 14 Mar 2015, at 22:20 , Bradley Giesbrecht wrote: >> The users I am attempting to serve currently get nothing because installing >> Xcode, CLT, MacPorts and then installing deps with non-default variants >> before building the target (octave in this case) is beyond their >> capabilities or patience. > > I absolutely can see where you are coming from… :-) > > Did you read the thread entitled > > "A (non)success story of digiKam on OSX/MacPorts involving kde4-workspace > and qtcurve” > > which I wrote this afternoon? Same thing! Yes I did. Yes, same thing. > Installing all these dependencies is only acceptable for techies like us, but > a normal > user will never bother to deal with all the hassle. I think we have an opportunity to extend what MacPorts does well to include relocatable packages or mdmg packages in a way that third parties can build distributable packages untethered from MacPorts and Xcode. Gimp, Kdenlive, digiKam, Octave and many KDE "things" would sing praises to MacPorts. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts hosted mdmg
Brad, On 14 Mar 2015, at 22:20 , Bradley Giesbrecht wrote: > The users I am attempting to serve currently get nothing because installing > Xcode, CLT, MacPorts and then installing deps with non-default variants > before building the target (octave in this case) is beyond their capabilities > or patience. I absolutely can see where you are coming from… :-) Did you read the thread entitled "A (non)success story of digiKam on OSX/MacPorts involving kde4-workspace and qtcurve” which I wrote this afternoon? Same thing! Installing all these dependencies is only acceptable for techies like us, but a normal user will never bother to deal with all the hassle. Greets, Marko signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts hosted mdmg
On Mar 14, 2015, at 12:18 PM, Rainer Müller wrote: > On 2015-03-14 14:44, Clemens Lang wrote: >> - On 14 Mar, 2015, at 02:04, Bradley Giesbrecht pixi...@macports.org >> wrote: >> >>> Has there been a discussion about having the MacPorts buildbots also build >>> mdmg >>> files? >>> >>> This may require a lot of resources so perhaps mdmg could be run for some >>> percentage of requested ports using mpstats? > > Not all ports will work when installed as mdmg. The main problem would > be that post-activate scripts are not converted to postflight scripts. > > There once was a dp_lite (DarwinPorts Lite) to extract a minimal runtime > to be included in standalone installers. > > As we now ship Tcl with base, we probably even had to include a Tcl > interpreter. Our code base is also not organized to isolate a few > commands. As post-activate scripts might run any command, I guess we > would end up with almost everything anyway... > >> What would be your use case for that? If you are looking for packages you can >> install without installing MacPorts, I'd argue it's a bad idea to have our >> buildbots generate those, because of the prefix conflict. > > Even when using a different prefix (ignoring all user confusion), this > would give the wrong impression of being an officially supported method > of installation. Users do not get any upgrade path with mdmg packages. The users I am attempting to serve currently get nothing because installing Xcode, CLT, MacPorts and then installing deps with non-default variants before building the target (octave in this case) is beyond their capabilities or patience. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts hosted mdmg
On 2015-03-14 14:44, Clemens Lang wrote: > - On 14 Mar, 2015, at 02:04, Bradley Giesbrecht pixi...@macports.org > wrote: > >> Has there been a discussion about having the MacPorts buildbots also build >> mdmg >> files? >> >> This may require a lot of resources so perhaps mdmg could be run for some >> percentage of requested ports using mpstats? Not all ports will work when installed as mdmg. The main problem would be that post-activate scripts are not converted to postflight scripts. There once was a dp_lite (DarwinPorts Lite) to extract a minimal runtime to be included in standalone installers. As we now ship Tcl with base, we probably even had to include a Tcl interpreter. Our code base is also not organized to isolate a few commands. As post-activate scripts might run any command, I guess we would end up with almost everything anyway... > What would be your use case for that? If you are looking for packages you can > install without installing MacPorts, I'd argue it's a bad idea to have our > buildbots generate those, because of the prefix conflict. Even when using a different prefix (ignoring all user confusion), this would give the wrong impression of being an officially supported method of installation. Users do not get any upgrade path with mdmg packages. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts hosted mdmg [eom]
On Mar 14, 2015, at 6:44 AM, Clemens Lang wrote: > Hi, > > - On 14 Mar, 2015, at 02:04, Bradley Giesbrecht pixi...@macports.org > wrote: > >> Has there been a discussion about having the MacPorts buildbots also build >> mdmg >> files? >> >> This may require a lot of resources so perhaps mdmg could be run for some >> percentage of requested ports using mpstats? > > What would be your use case for that? If you are looking for packages you can > install without installing MacPorts, Yes. > I'd argue it's a bad idea to have our > buildbots generate those, because of the prefix conflict. And I'd agree though there are groups of consumers (sciences) that would likely never install MacPorts if they could use installers. This is not the best use of MacPorts resources. I quash my idea. Regards, Bradley Giesbrecht (pixilla) signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: MacPorts hosted mdmg
Hi, - On 14 Mar, 2015, at 02:04, Bradley Giesbrecht pixi...@macports.org wrote: > Has there been a discussion about having the MacPorts buildbots also build > mdmg > files? > > This may require a lot of resources so perhaps mdmg could be run for some > percentage of requested ports using mpstats? What would be your use case for that? If you are looking for packages you can install without installing MacPorts, I'd argue it's a bad idea to have our buildbots generate those, because of the prefix conflict. See http://guide.macports.org/#using.binaries.binary-packages and http://trac.macports.org/wiki/ProblemHotlist#xmlwf. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
