A Plea to Reduce Dependences (e.g., for swig)

[Anders F Björklund]

Jordan K. Hubbard wrote:

> On Aug 24, 2011, at 12:06 PM, Ryan Schmidt wrote:
> 
>> And I think we all know that Apple prides itself on producing software that has *few* options. Apple does *not* add an option to iTunes or iOS just because one power user thinks it might be fun to play with. Apple provides default functionality that is correct for maybe 80% of users, and a few carefully-selected options for maybe another 10% of users, and tells the remaining 10% tough beans. And this is great because what happens otherwise is that inexperienced users get overwhelmed by settings and choices they don't understand, or they select options without understanding their consequences.
> 
> Hi Ryan,
> 
> I cannot disagree with your overall sentiment.  Adding another option for "use system bits" would almost certainly create a combinatorial explosion of different user scenarios and make debugging and "tech support" for MacPorts even more problematic than it is now.

You could add a different ports tree (or several actually, one for each OS) like the original poster did with his ports. That's maybe not another globally confusing flag like +universal or +system_x11, but still something of a "fork" of the ports ? But I always thought that MacPorts was for when you got tired of the provided options and wanted to pick a few of your own... Maybe not.

> I guess, then, that this is really an appeal to hide the details since you can only get away with doing things "the Apple way" if you also hide the majority of the working parts from the end-user.  In MacPorts' case, this would essentially mean having a GUI tool which allowed one to click away on various packages to one's hearts content and then click "Go!" and have all the right deps installed transparently and with a minimum of download and CPU resources consumed.

Unless somebody completes Pallet, the only working GUI would be Port Authority. And that is still too technical for most users, since they don't want to hear about ports/packages but about apps/software. With icons. Big icons. <sigh> So it would need something more "App Store", first. Like what happened in Ubuntu, when the Synaptic tool changed into the Software Centre.

> Until you have that, however, then the "few options" defense just doesn't work for you because that's not what MP provides, or anything even reasonably close right now.  Right now, it's a build tool created for experts by experts (and sorry, but anyone who knows how to open Terminal.app and type shit is an "expert" by the Apple definition).  The experts see all of the machinations and the extra bits being installed and then they go blog about how Homebrew is the future of package management for Mac OS X. :-)

Except that it doesn't have packages, of course. Just for a few select ports that take ages to build (like Qt or Boost). But otherwise the Homebrew packages ("bottles") works the same as the MacPorts packages ("archives"), and are more or less a pre-build destroot - still requiring the build tool. Ultimately, using packages shouldn't require either of Developer Tools or Terminal.

The only "few options" alternatives available are using Installer.app .pkg (bundling and re-installing each and every dependency, since the dependency management isn't available or at least working as required) or using Fink, but they don't provide an updated binary distribution or updated graphic tools either - even if they do have actual binary packages (in the form of .deb).

Originally the main reason for avoiding .pkg was that it isn't open source, but eventually it was more the implementation bugs and the poor compression and the lack of uninstallation that made it something that one wants to avoid if at all possible. The lack of a build system and dependency management doesn't help either. But since everybody hates RPM, we need *another* one.


So that was why despite having four package managers (port, fink, brew, rpm) installed, I *still* have to build everything manually...

And that absolutely doesn't help at all with reducing dependencies or the installed size, since now I have five versions of each thing.

> And before anyone says it, yes, I know that Apple is currently assisting the project in creating just that sort of binary package delivery infrastructure, and I really hope the effort succeeds since god only knows how much even I am tired of listening to myself harp on that particular topic, I'm just saying that MacPorts is currently at that "awkward age" where it's neither fish nor fowl, and that means that you really can't wrap yourselves in the clothing of "ease of use" just yet.  Keep that argument warm for when it's actually applicable though, yes, indeed. ;-)


I'm guessing that *most* of the macports port installation complaints will go away now, with the packages.macports.org archives up ?

The best package management tool is the one that is invisible to the user, since it's about as interesting to watch as solving sudoku.


Still preferring Zero Install,
--anders

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110827/283de8e6/attachment.html>