Re: Package delivery without XCode
I agree. Sometimes even I use these methods instead of MacPorts, but I usually try to get Macports to work as hard as I can. VLC is the one offender that really doesn't want to build sometimes. —Mark ___ Mark E. Anderson e...@emer.net On Mon, May 18, 2015 at 8:04 PM, Ryan Schmidt ryandes...@macports.org wrote: On May 18, 2015, at 4:11 PM, Craig Treleaven wrote: Right now, as I see it, MacPorts is pretty much geared to coders and sophisticated users (system/network administrators, etc). There exists a wider group of folks who just want to run a specific application or two (say Darktable and Gimp, just for instance). If such users could just install Pallet-lite and then be able to install any of a few dozen major open-source applications, that might be pretty popular. Most of the software in MacPorts is something you would use from the command line (e.g. ImageMagick), or something that is server software (e.g. Apache or PostgreSQL) or is a compiler or interpreter for a programming language (e.g. PHP or Node or GCC). Users of such software would hopefully be comfortable using MacPorts from the command line. There's no reason why users who aren't comfortable with the command line (the wider group of folks you mention) can't also use MacPorts. It should not be beyond anyone's capabilities to read and follow the MacPorts installation instructions, and to type a few commands into a terminal window to install the software they want. And those who prefer to use a MacPorts GUI have a few choices for that. Hopefully Pallet will be a viable option again sometime in the future when it's fixed up. I think there was even a recent proposal from someone to do that. Most GUI software designed for the Mac is already distributed in a ready-to-install way by those respective projects. Your two examples, Gimp and Darktable, already are, for example. For a lot of GUI software, e.g. VLC, it's simply a lot less bother to just use the binaries the developers provide rather than trying to use MacPorts to install it. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Package delivery without XCode
At 8:45 AM -0700 5/18/15, David Evans wrote: On 5/18/15 8:01 AM, Craig Treleaven wrote: Background - So I was following a discussion on another site about Apple's Aperture being replaced. Many people are looking for alternatives and there has been essentially no mention of open source alternatives (like DarkTable, LightZone or DigiKam). Most of these folks are photographers and would never consider installing MacPorts and XCode in order to get an application they might otherwise find interesting. 1) How much work would it take to have a mode in MacPorts where it only installs pre-compiled packages? Is the assumption that XCode is present so deeply ingrained that Macports-base would have to be extensively re-designed? For example, I would think 'port search' would need to be modified to only show the pre-compiled packages (available for that platform) and somehow indicate that only the default variants are available. Perhaps a fork of Pallet could be so modified? 2) Are there a worthwhile number of packages that would then be available? I know my own MythTV ports run into the OpenSSL conflict and therefore aren't available as binaries. From http://packages.macports.org/ it appears we don't have binary packages for DarktTable or DigiKam (and no port of LightZone). OTOH, someone posted some information several weeks ago explaining how to determine if that licence conflict really applies or not. (Involves inspecting library linkages, as I recall.) I get the impression that our current policy is quite conservative and that a number of packages (many?) may actually qualify for binary distribution with some analysis and verification. Have you looked at the various binary packaging targets available with MacPorts? mpkg or mdmg might provide a mechanism to do what you want. Just would need a way to distribute the results providing the licensing issues could be worked out. See https://guide.macports.org/#using.binaries I am intimately familiar with mpkg/mdmg -- I provide an all-in-one installer for Myth[1]. For that, I use Parallels to maintain an isolated prefix for building (and others for testing. It occurred to me that the existing infrastructure of MacPorts provides _most_ of what would be needed for delivering pre-built packages to less-sophisticated users. [1] https://sourceforge.net/projects/macportsmythtvinstaller/ Craig ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Package delivery without XCode
On Mon, May 18, 2015 at 11:01 AM, Craig Treleaven ctrelea...@macports.org wrote: 1) How much work would it take to have a mode in MacPorts where it only installs pre-compiled There is already buildfromsource never settable in macports.conf. OTOH, someone posted some information several weeks ago explaining how to determine if that licence conflict really applies or not. (Involves inspecting library linkages, as I recall.) I get the impression that our current policy is quite conservative and that a number of packages (many?) may actually qualify for binary distribution with some analysis and verification. But someone needs to put in that time --- and time is always a problem in a volunteer-run project. If you install a separate MacPorts from source in a different prefix than /opt/local (so people don't have to *avoid* MacPorts conflicts), you can make drag-and-drop installable apps. There are also tools to help make self-contained app bundles, although that requires manual intervention. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Package delivery without XCode
On 5/18/15 8:01 AM, Craig Treleaven wrote: Background - So I was following a discussion on another site about Apple's Aperture being replaced. Many people are looking for alternatives and there has been essentially no mention of open source alternatives (like DarkTable, LightZone or DigiKam). Most of these folks are photographers and would never consider installing MacPorts and XCode in order to get an application they might otherwise find interesting. 1) How much work would it take to have a mode in MacPorts where it only installs pre-compiled packages? Is the assumption that XCode is present so deeply ingrained that Macports-base would have to be extensively re-designed? For example, I would think 'port search' would need to be modified to only show the pre-compiled packages (available for that platform) and somehow indicate that only the default variants are available. Perhaps a fork of Pallet could be so modified? 2) Are there a worthwhile number of packages that would then be available? I know my own MythTV ports run into the OpenSSL conflict and therefore aren't available as binaries. From http://packages.macports.org/ it appears we don't have binary packages for DarktTable or DigiKam (and no port of LightZone). OTOH, someone posted some information several weeks ago explaining how to determine if that licence conflict really applies or not. (Involves inspecting library linkages, as I recall.) I get the impression that our current policy is quite conservative and that a number of packages (many?) may actually qualify for binary distribution with some analysis and verification. Craig ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev Hi, Craig -- Have you looked at the various binary packaging targets available with MacPorts? mpkg or mdmg might provide a mechanism to do what you want. Just would need a way to distribute the results providing the licensing issues could be worked out. See https://guide.macports.org/#using.binaries Dave ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Package delivery without XCode
On May 18, 2015, at 10:01, Craig Treleaven wrote: Perhaps a fork of Pallet could be so modified? First Pallet would have to be fixed so that it works again. There are open tickets. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Package delivery without XCode
At 11:56 AM -0400 5/18/15, Brandon Allbery wrote: On Mon, May 18, 2015 at 11:01 AM, Craig Treleaven mailto:ctrelea...@macports.orgctrelea...@macports.org wrote: ... OTOH, someone posted some information several weeks ago explaining how to determine if that licence conflict really applies or not. (Involves inspecting library linkages, as I recall.) I get the impression that our current policy is quite conservative and that a number of packages (many?) may actually qualify for binary distribution with some analysis and verification. But someone needs to put in that time --- and time is always a problem in a volunteer-run project. Understood, I'm trying to gauge whether there is interest in taking MacPorts in this direction. Right now, as I see it, MacPorts is pretty much geared to coders and sophisticated users (system/network administrators, etc). There exists a wider group of folks who just want to run a specific application or two (say Darktable and Gimp, just for instance). If such users could just install Pallet-lite and then be able to install any of a few dozen major open-source applications, that might be pretty popular. In some ways, it might be the Mac App Store for open source. Craig ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Package delivery without XCode
On May 18, 2015, at 5:11 PM, Craig Treleaven ctrelea...@macports.org wrote: At 11:56 AM -0400 5/18/15, Brandon Allbery wrote: On Mon, May 18, 2015 at 11:01 AM, Craig Treleaven mailto:ctrelea...@macports.orgctrelea...@macports.org wrote: ... OTOH, someone posted some information several weeks ago explaining how to determine if that licence conflict really applies or not. (Involves inspecting library linkages, as I recall.) I get the impression that our current policy is quite conservative and that a number of packages (many?) may actually qualify for binary distribution with some analysis and verification. But someone needs to put in that time --- and time is always a problem in a volunteer-run project. Understood, I'm trying to gauge whether there is interest in taking MacPorts in this direction. Right now, as I see it, MacPorts is pretty much geared to coders and sophisticated users (system/network administrators, etc). There exists a wider group of folks who just want to run a specific application or two (say Darktable and Gimp, just for instance). If such users could just install Pallet-lite and then be able to install any of a few dozen major open-source applications, that might be pretty popular. In some ways, it might be the Mac App Store for open source. we essentially have had that at different times in the past - there was an old branch that pushed the build products into rpms and did install only from rpms too (so MacPorts was just a build system and didn’t have to do any of the package management stuff). as a project, we need to decide if we want to extend MacPorts to make it less of an 80% package-manager solution (and if so, who is going to work on it?) or if it makes sense to once again look to leverage another project (just pick a package manager and have macports feed into it). -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Package delivery without XCode
On May 18, 2015, at 4:11 PM, Craig Treleaven wrote: Right now, as I see it, MacPorts is pretty much geared to coders and sophisticated users (system/network administrators, etc). There exists a wider group of folks who just want to run a specific application or two (say Darktable and Gimp, just for instance). If such users could just install Pallet-lite and then be able to install any of a few dozen major open-source applications, that might be pretty popular. Most of the software in MacPorts is something you would use from the command line (e.g. ImageMagick), or something that is server software (e.g. Apache or PostgreSQL) or is a compiler or interpreter for a programming language (e.g. PHP or Node or GCC). Users of such software would hopefully be comfortable using MacPorts from the command line. There's no reason why users who aren't comfortable with the command line (the wider group of folks you mention) can't also use MacPorts. It should not be beyond anyone's capabilities to read and follow the MacPorts installation instructions, and to type a few commands into a terminal window to install the software they want. And those who prefer to use a MacPorts GUI have a few choices for that. Hopefully Pallet will be a viable option again sometime in the future when it's fixed up. I think there was even a recent proposal from someone to do that. Most GUI software designed for the Mac is already distributed in a ready-to-install way by those respective projects. Your two examples, Gimp and Darktable, already are, for example. For a lot of GUI software, e.g. VLC, it's simply a lot less bother to just use the binaries the developers provide rather than trying to use MacPorts to install it. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
