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

[Ben Greenfield]

Hey All,

I have been using MacPorts for years and the way I use it works because of /opt/local/. If  the notion of  everything living under /opt/local went away I would have to change my process. 

I do my building on a single machine and rsync out the /opt/local/ results to my clients. I have always considered it a great design and I want to encourage maintaining the /opt/local/. If things were built and spread out across the file tree my methods become more complicated. This also protects my production /opt/local/ from MacPorts build process breaking.


On Aug 28, 2011, at 6:13 AM, Anders F Björklund wrote:

> Ryan Schmidt wrote:
> 
>>> 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.
>> 
>> The response to this suggestion has always been that we do not have sufficient human resources to maintain our one single ports tree that we have today; we certainly do not have the resources to maintain multiple divergent trees.
> 
> Right. That's why it's been easier to use a totally separate tree,
> instead of making MacPorts do something that it doesn't want to do.
> 
> But I guess you might as well be using a separate tool too, then...

I don't know what you mean by doing something  MacPorts doesn't want to do, but I have my own port files for programs that don't exist in MacPorts. 
I spend my time trying to get MacPorts to manage my  install so that I don't have to know about dependencies.

> 
>>> 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.
>> 
>> Two things. First, MacPorts isn't really for apps that have icons. Some of our ports are for apps that have icons, yes, but the vast majority are for command-line programs and libraries.
> 
> Most of those icons come from the packages themselves, the .desktop.
> (i.e. share/applications and images in share/pixmaps or share/icons)
> 
> But I didn't actually mean real app icons, just big shiny package icons.
> 
>> Second, MacPorts *is* about software. If a user wants, say, ImageMagick, they can "sudo port install ImageMagick". They don't need to care that MacPorts will install a bunch of other ports for them. In the end, the "convert" command will be installed in /opt/local/bin and they can use it, which is what they wanted.
> 
> Right, there's a few small caveats why it's "complicated":
> 
> 1) Installation requires a CLI. Fixed by using a GUI.
>   Sounds great that Pallet is complete / out of beta.
> 2) Installing from port/src requires Developer Tools.
>   Fixed by installing from package, where available.
> 3) Installation requires root/admin/sudo privileges.
>   Is changeable, but it currently conflicts with 2).
> 
> That it pulls it tons of dependencies is more "annoying",
> especially if it's more about bandwidth/storage than CPU ?
> It also installs a bunch of header files and static libraries,
> without sub-pkgs, but those are also more about space than time.

I'm so happy when I watch my computer struggling to work, so often it just sits there :)
I would set-up a single machine to do the building on then dependencies build-up and your ssd drive only gets what it needs.

> Like you say, all of these *could* be fixed within MacPorts...

What about expressing it like this "... all these features could be added to MacPorts in addition to the awesome way it already does it job."

>>> I'm guessing that *most* of the macports port installation complaints will go away now, with the packages.macports.org archives up ?
>> 
>> Most of the installation complaints that relate to ports taking a long time to compile, sure. Even most of the installation complaints relating to users installing random third-party software that mucks things up.
> 
> At least as long as all the "dupes" are being maintained...
> 
> The major annoyance is where the system version is working,
> but the MacPorts version is not. Like after a system upgrade ?
> As long as it finally completes, most don't complain (much)

The system version may not be current but working. If you do the building on single machine then only rsync to production once the build succeeds then you won't break your workflow.

Ben


> 
> --anders
> 
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev