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

[Anders F Björklund]

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...

>> 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.

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

>> 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)

--anders