Sorbet Leopard - Your Power Mac Unleashed

[srp]

I'd also like to know this too, as it would be a good incentive for me to dust off my PM G5 and explore the possibilities.

If you're interested, I keep a kanban board with a list of all of the software I have developed or ported to PowerPC:

https://trello.com/b/sSR62sz3/shays-ppc-software

Might be a good resource if you're looking for new things to do with your G5. 😉

 

[z970]

Rhythmbox build and works in its latest release. Did I miss anything?

If Rhythmbox, libimobiledevice, usbmuxd (and I believe a few other MTP libraries) will build, as well as gThumb and something like PCManFM if need be, that would in theory enable near-comprehensive syncing to modern iOS devices, sans the software restore functions exclusive to macOS / iTunes. If cups and cups-filters build, that would also restore compatibility with modern printers.

Likewise if something like Geary or Claws Mail will build, that would also supplant Mail.app as a modern email client. And if surf and its libwebkit2gtk / libjavascriptcoregtk dependencies will build, that would also fill the place of Leopard WebKit / Safari as a both lighter and non-Rust modern alternative to the Mozilla browsers -- assuming the hardware abstraction layers work and it can use the GPU.

If Snow Leopard is already actually that capable, perhaps there is a future where it can act as an effective intersection of OS X and Linux offering the best of both worlds, once the bugs have been ironed out providing all of the elusive hardware compatibility of the former (working sleep, X1900 compatibility), together with the coveted modern software access of the latter. In that case there would no longer be almost any need to spend time exploring Linux (troubleshooting a broken GRUB / missing kernel modules / strange trackpad response / etc) for the vast majority, unless security of the OS itself is a high priority.

But if the kernel and all AOSP frameworks, libraries, and applicable binaries can be rebuilt to modern versions, that then resolves a significant chunk of the security factor albeit likely at the progressive cost of stability. But at the same time that would be such an undertaking, it is almost a completely different project altogether; given the factors you cited of most people having limited time / resources, I can't imagine anyone would actually take that one on.

This is why having a custom kernel is so important! We can patch Darwin syscalls for POSIX compliance now - this means you can fix an entire *category* of errors. I figured you'd be ecstatic about something like this because by patching these things at the source, you're saving hours of effort downstream in every affected port.

The work is narrow enough in scope where you'd really only have to make these patches once and you'd vastly improve the compatibility and reliability of our development environment and get a lot of the benefits you're talking about without ever having to step foot off of a rock solid, official release platform.

Completely agreed (this and everything else). If the bugs in Snow Leopard can never be resolved given many kexts and frameworks are nonetheless closed-source and / or do not function properly with equivalent imports from 10.5.8, this would by far be the next best route.

 

[Forest Expertise]

If Rhythmbox, libimobiledevice, usbmuxd (and I believe a few other MTP libraries) will build, as well as gThumb and something like PCManFM if need be, that would in theory enable near-comprehensive syncing to modern iOS devices, sans the software restore functions exclusive to macOS / iTunes. If cups and cups-filters build, that would also restore compatibility with modern printers.

Likewise if something like Geary or Claws Mail will build, that would also supplant Mail.app as a modern email client. And if surf and its libwebkit2gtk / libjavascriptcoregtk dependencies will build, that would also fill the place of Leopard WebKit / Safari as a both lighter and non-Rust modern alternative to the Mozilla browsers -- assuming the hardware abstraction layers work and it can use the GPU.

If Snow Leopard is already actually that capable, perhaps there is a future where it can act as an effective intersection of OS X and Linux offering the best of both worlds, once the bugs have been ironed out providing all of the elusive hardware compatibility of the former (working sleep, X1900 compatibility), together with the coveted modern software access of the latter. In that case there would no longer be almost any need to spend time exploring Linux (troubleshooting a broken GRUB / missing kernel modules / strange trackpad response / etc) for the vast majority, unless security of the OS itself is a high priority.

But if the kernel and all AOSP frameworks, libraries, and applicable binaries can be rebuilt to modern versions, that then resolves a significant chunk of the security factor albeit likely at the progressive cost of stability. But at the same time that would be such an undertaking, it is almost a completely different project altogether; given the factors you cited of most people having limited time / resources, I can't imagine anyone would actually take that one on.



Completely agreed (this and everything else). If the bugs in Snow Leopard can never be resolved given many kexts and frameworks are nonetheless closed-source and / or do not function properly with equivalent imports from 10.5.8, this would by far be the next best route.

If you are ever curious about what is currently working on 10.5.8, you can check out Matias's prebuilt binaries - https://kemonomimi.nl/ppcports/software/
Similarly, one can check my pre built binaries for an idea of what works on Tiger. Time, resources, and expertise are the most important factors in fixing stuff. Tiger is in bad shape mostly because we do not have as many people with experience working on it - it would take at least 156 people of my skill level and time management to do anything close to what Barracuda156 can do.
Claws-mail works great, I even have that on Tiger. I got an earlier version on gthumb to build once on Tiger - I am unsure if the current builds on Leopard since I don't see it in the prebuilt repo. Webkitgtk2 based browsers would be difficult to fix even on Snow Leopard PowerPC, much less earlier OS X, and the version in Macports is outdated enough it may be simpler to start from a clean slate. Webkitgtk2 is arguably the largest advantage MorphOS, ARCHPower and Debian will have over OS X for the foreseeable future.
I can't find any existing work for PCManFM.
Cups-pdf builds on Tiger, I am unsure if that is equivalent to what you mentioned.
usbmuxd and libmobiledevice build on Tiger, so I am sure they do on Leopard. Maybe rhythmbox also does but I have yet to confirm that
Operating system choice is a tradeoff between old proprietary software and new open source software for PowerPC. Everyone has their own priorities, and it's great to support each other even if our priorities differ. People achieving something on their OS of choice usually makes it easier to achieve something similar on another PowerPC OS.
Btw, thank you @z970 for distributing the Shuriken collection of scripts!

 

[barracuda156]

If Rhythmbox, libimobiledevice, usbmuxd (and I believe a few other MTP libraries) will build, as well as gThumb and something like PCManFM if need be, that would in theory enable near-comprehensive syncing to modern iOS devices, sans the software restore functions exclusive to macOS / iTunes. If cups and cups-filters build, that would also restore compatibility with modern printers.

Likewise if something like Geary or Claws Mail will build, that would also supplant Mail.app as a modern email client. And if surf and its libwebkit2gtk / libjavascriptcoregtk dependencies will build, that would also fill the place of Leopard WebKit / Safari as a both lighter and non-Rust modern alternative to the Mozilla browsers -- assuming the hardware abstraction layers work and it can use the GPU.

Claws Mail was and is building and working for a long time. libimobiledevice builds, gthumb builds, others need to check.

I keep getting impression that nobody is aware of what we have. A huge part of MacPorts works, perhaps way more than half. Many apps in newer versions than on much newer macOS versions (thanks to libstdc++).

Most math ports and large part of science ones work. For sure a bunch of trivial libraries will.

WebKit2 will be a trouble, being a pile of garbage code, essentially. I recall Ken mentioning that when he once got some old version to work, it was barely usable. (Sadly, it’s a general tendency to use 2–3 bloated and messed JS engines, and it is hard to port a lot of bad code.)
Having said that, webkit2gtk should be doable. JIT has to be added or excluded from the build.

Admittedly, constraint of “no Qt5+” hits hard, and rewriting Qt6 apps to Qt4 is very involving, but most Linux apps that use GTK or X11 will work or already work.

Unless we talk about exotic non-portable languages like Go, chances are high that any arbitrary opensource app will work.
To put it elsewise: it makes sense to check if ports have a given port already.

If Snow Leopard is already actually that capable, perhaps there is a future where it can act as an effective intersection of OS X and Linux offering the best of both worlds, once the bugs have been ironed out providing all of the elusive hardware compatibility of the former (working sleep, X1900 compatibility), together with the coveted modern software access of the latter. In that case there would no longer be almost any need to spend time exploring Linux (troubleshooting a broken GRUB / missing kernel modules / strange trackpad response / etc) for the vast majority, unless security of the OS itself is a high priority.

But if the kernel and all AOSP frameworks, libraries, and applicable binaries can be rebuilt to modern versions, that then resolves a significant chunk of the security factor albeit likely at the progressive cost of stability. But at the same time that would be such an undertaking, it is almost a completely different project altogether; given the factors you cited of most people having limited time / resources, I can't imagine anyone would actually take that one on.



Completely agreed (this and everything else). If the bugs in Snow Leopard can never be resolved given many kexts and frameworks are nonetheless closed-source and / or do not function properly with equivalent imports from 10.5.8, this would by far be the next best route.

 

[TheShortTimer]

What in particular?

It is easy to say what will not work (at least not without a lot of work): Go software, Rust software, NodeJS, Swift, modern ObjC software with hard dependency on system frameworks missing in 10.6, Qt6, dotnet (modern C#), OpenGL 3.x+. Everything else not covered by this should be buildable or fixable.

As things stand, what is probably the most affected area is the web: specifically, browsers and messengers (because a lot of those depend on broken stuff listed above: rust, go, qt6, node). Working solutions exist, but severely limited.

I looked at FreeBSD’s LibreOffice port: https://github.com/freebsd/freebsd-ports/blob/main/editors/libreoffice/Makefile
I think there is nothing in it which would prevent building it. Possibly Java will need to be disabled. Qt won’t work, but GTK will.
That gonna be a huge endeavor though, not something to do in a lunch break 🙂

I've always understood that we're all volunteers and as such, I've always been grateful for whatever people have provided to the community. What I would like to see is a fairly up to date version of MAME (or SDL MAME if possible), VLC and top of my wish list would be a native PPC macOS version of the Sega Supermodel emulator - seeing as it's based around hardware that's PPC in the first place.

People have taken a look at the source code and told me that it would be a nightmare to deal with, so I suppose that will remain a "wouldn't be it be nice?" scenario.

If you're interested, I keep a kanban board with a list of all of the software I have developed or ported to PowerPC:

https://trello.com/b/sSR62sz3/shays-ppc-software

Might be a good resource if you're looking for new things to do with your G5. 😉

Thank you! There's lots of goodies on there and I've bookmarked the page. You've been very busy! 😀

 

[z970]

I keep getting impression that nobody is aware of what we have. A huge part of MacPorts works, perhaps way more than half. Many apps in newer versions than on much newer macOS versions (thanks to libstdc++).

You are likely correct in that synopsis. It is a guess, but perhaps it is because people who don't have previous experience installing IDEs, finding / loading source code, and starting compilation cycles don't naturally gravitate to innovations in this circle even when it can open up tangible new opportunities. Doing further research however, it is clear that PPCPorts has made the overall setup process a great deal easier from presumably what it was otherwise, and certainly there is value in that.

I think if an actual unified installer was provided to install xtools, make, curl, etc in one go so that setup is just a matter of grabbing Xcode and running the installer, more support / resources were provided for 10.5 rather than 10.6 (wherever possible) because that is what most people are using, and that the project was also marketed more effectively to communicate the new advancements it provides and how it also democratizes the software development process by now making it available to anyone (or something like that), then I'm sure it would catch on much faster since most would probably appreciate the ability to easily assemble something themselves instead of waiting for someone better equipped to do it. Ergo, more people benefit from these projects by building software that they wouldn't have otherwise; just look at the recent explosion of vibe coding of this phenomenon in practice.

You have to meet folks where they are, and while there is a lot of hobbyist / enthusiast traffic here, only a portion seem to have the developer mindset that would naturally predispose them to benefiting from these tools (and of course there is nothing wrong with that). But if the above improvements were made for example, PPCPorts could easily be plastered onto the front page in the Sorbet App Store, written in news articles, and featured in videos for the average user to get involved with because the barriers to entry would be even further lowered and inherent value clearly communicated. Then no doubt a lot more would be aware of what we have.

But now I am thinking out loud again. They are all just ideas, I suppose...

One more silly question from a layman: If something was built natively for 10.5 using MacPorts or PPCPorts, for example VLC, would it be able to run independently on another 10.5 system with no development libraries installed?

 

[barracuda156]

I've always understood that we're all volunteers and as such, I've always been grateful for whatever people have provided to the community. What I would like to see is a fairly up to date version of MAME (or SDL MAME if possible), VLC and top of my wish list would be a native PPC macOS version of the Sega Supermodel emulator - seeing as it's based around hardware that's PPC in the first place.

VLC is already there (no Cocoa GUI, but the player works via X11), though there are better choices for multimedia players, IMO: qmplay2, mpv, mplayer.

Someone asked about MAME, it should be doable, but it takes forever to compile, so when I tried, I eventually just interrupted the build and left it at that. I can’t afford running something for 20+ hrs unless it is gcc build (and likely it won’t be just a single build run, something will need to be fixed on the go). So the only scenario where I consider dealing with it is if I have an ssh access to a fast machine where I can run builds, access logs and make fixes.

I can’t say anything about the last one, I haven’t seen the codebase of that emulator.

 

[TheShortTimer]

VLC is already there (no Cocoa GUI, but the player works via X11), though there are better choices for multimedia players, IMO: qmplay2, mpv, mplayer.

I'll have a look at the others in that case. Excuse my ignorance, have the PPC versions been updated with support for newer codecs?

Someone asked about MAME, it should be doable, but it takes forever to compile, so when I tried, I eventually just interrupted the build and left it at that. I can’t afford running something for 20+ hrs unless it is gcc build (and likely it won’t be just a single build run, something will need to be fixed on the go). So the only scenario where I consider dealing with it is if I have an ssh access to a fast machine where I can run builds, access logs and make fixes.

Sounds like you need someone who'd be prepared to take the hit on their electricity bill! I might be that person…

I can’t say anything about the last one, I haven’t seen the codebase of that emulator.

Here you go. 🙂

 

[barracuda156]

I'll have a look at the others in that case. Excuse my ignorance, have the PPC versions been updated with support for newer codecs?

We have the latest versions of ffmpeg and pretty much every multimedia library.

Of course, supporting a codec does not guarantee that it will perform good enough on an arbitrary hardware (this is not a problem of ppcports or macOS, but a hardware constraint plus a fact that often SIMD implementations do not exist for powerpc).

Sounds like you need someone who'd be prepared to take the hit on their electricity bill! I might be that person…

Well, I already run the still-alive PowerMac multiple hours daily and cutting A/C usage to keep costs sane, and it is 30+C here…

Here you go. 🙂

From the quick look there is nothing that would make it impossible (mostly C++, SDL for GUI, a little of ObjC and GLSL). However:
1. If it assumes GL 3.0+ (and likewise GLSL 1.3 or whatever corresponds to that), those parts of code have to be adapted to use GL 2.0. It is generally feasible, but can be demanding (it depends).
2. Does it work on some Big-endian platform? If not, there is a chance of hell breaking loose at runtime lol
3. If ObjC code relies on some modern frameworks, that must be rewritten.

 

[barracuda156]

If Rhythmbox, libimobiledevice, usbmuxd (and I believe a few other MTP libraries) will build, as well as gThumb and something like PCManFM if need be, that would in theory enable near-comprehensive syncing to modern iOS devices, sans the software restore functions exclusive to macOS / iTunes. If cups and cups-filters build, that would also restore compatibility with modern printers.

@z970 Besides, is this a rhetorical statement or are you gonna actually test and use these? There are no ports for some of these, apparently, so I (or someone) needs to write those. pcmanfm should work, unless it requires some Linux-only stuff.

Update: pacmanfm and its dependencies added in:

pcmanfm: new port · macos-powerpc/powerpc-ports@81b689d

Overlay repo with fixes to use with MacPorts on macOS PowerPC - pcmanfm: new port · macos-powerpc/powerpc-ports@81b689d

github.com

libfm: new port · macos-powerpc/powerpc-ports@d099e05

Overlay repo with fixes to use with MacPorts on macOS PowerPC - libfm: new port · macos-powerpc/powerpc-ports@d099e05

github.com

libmenu-cache: new port · macos-powerpc/powerpc-ports@d2bd416

Overlay repo with fixes to use with MacPorts on macOS PowerPC - libmenu-cache: new port · macos-powerpc/powerpc-ports@d2bd416

github.com

 

[Forest Expertise]

One more silly question from a layman: If something was built natively for 10.5 using MacPorts or PPCPorts, for example VLC, would it be able to run independently on another 10.5 system with no development libraries installed?

Sort of. You can make an application installer as follows
1. Install Macports or PowerPC ports from source into a custom prefix, such as opt/applicationname. Detailed instructions from @barracuda156 are in the sdl2 thread on this forum.
2. Sudo port install -v applicationname
3. Sudo port mdmg applicationname
4. You should now have a DMG of the application and it's libraries that can be installed and work on nearly identical systems.
A curl installer is trivial, and portable across G4 vs G5 and 10.5.8 vs 10.5.9. Something more involved, like this claws-mail installer I made https://macintoshgarden.org/apps/claws-mail only works on Altivec capable Tiger Client 10.4.11 machines and is around 800 MB when installed.
Application installers make things a little more accessible, but keeping more than a few up to date would be a big task, because everything is in separate prefixes, has to be built separately, and can't use pre built binaries. The process can also be quirky for large applications. Still worth it if you want to reach a wider audience.

 

[barracuda156]

Sort of. You can make an application installer as follows
1. Install Macports or PowerPC ports from source into a custom prefix, such as opt/applicationname. Detailed instructions from @barracuda156 are in the sdl2 thread on this forum.
2. Sudo port install -v applicationname
3. Sudo port mdmg applicationname
4. You should now have a DMG of the application and it's libraries that can be installed and work on nearly identical systems.

I think you do not need to install the app, mpkg and mdmg should work without that. (Ports which I use to build system components explicitly prohibit installing them directly, for example.)

 

[srp]

I think you do not need to install the app, mpkg and mdmg should work without that. (Ports which I use to build system components explicitly prohibit installing them directly, for example.)

What about a PPCPorts GUI? A proper visual package manager that wraps the commands…

This could be helpful in resolving some of the concerns about ease of use.

 

[barracuda156]

What about a PPCPorts GUI? A proper visual package manager that wraps the commands…

This could be helpful in resolving some of the concerns about ease of use.

I don’t know how that could possibly look like. Of course, a rich GUI, with screenshots of apps, sorting by categories etc. would be nice for the purpose of introducing existing stuff, but that’s like writing a new Apple Store, plus someone needs to make all those app previews. On the other hand, a basic TUI duplicating same stuff that can be done in CLI, seems redundant: yeah, it gonna look marginally better, but still a lot of work, and with little utility.

 

[z970]

Besides, is this a rhetorical statement or are you gonna actually test and use these? There are no ports for some of these, apparently, so I (or someone) needs to write those. pcmanfm should work, unless it requires some Linux-only stuff.

I was asking to gain a better understanding of what the possibilities are at this stage, and graciously, thanks to your explanations and @Forest Expertise, I as well as anyone else reading the thread are now more informed.

Considering the availability of Finder, the only utility in PCManFM in particular (that I can think of) is if it can be paired with libimobiledevice to enable file transfer with modern iOS devices as--unless I am mistaken--I can't imagine that libimobiledevice (and similar active libraries if any) would be able to talk directly with Finder instead out-of-the-box... unless perhaps using Xcode they were installed into a new kext or framework that could serve as a shim interface between them and Finder, supplanting the need for a second file manager. But that is another project not quite on my screen at the moment.

What about a PPCPorts GUI? A proper visual package manager that wraps the commands…

This could be helpful in resolving some of the concerns about ease of use.

If nothing else, perhaps it could just walk the user through the installation process using normal language. As in, it announces what it's going to do next, requests permission for each stage, and executes the steps behind the scenes while the user keeps clicking "Continue" to run successive commands.

Further still, maybe after it finishes setting up the development environment, it can display a list of selections of working software for the OS it's being run on, then proceed to download the materials for the selected application(s), run a build, and then automatically deposit the finished binary into /Applications. Very similar in design to tasksel during the installation of a Debian system.

If people would like better access to modern software on OS X, I think such a device would dramatically improve ease of use for sure.

 

[barracuda156]

Considering the availability of Finder, the only utility in PCManFM in particular (that I can think of) is if it can be paired with libimobiledevice to enable file transfer with modern iOS devices as--unless I am mistaken--I can't imagine that libimobiledevice (and similar active libraries if any) would be able to talk directly with Finder instead out-of-the-box... unless perhaps using Xcode they were installed into a new kext or framework that could serve as a shim interface between them and Finder, supplanting the need for a second file manager. But that is another project not quite on my screen at the moment.

@z970 PCManFM is now available. I do not know if it will be useful for the said task. Looks like at least FreeBSD does not state libimobiledevice as a dependency for any file manager: https://www.freshports.org/comms/libimobiledevice (at least not directly, maybe it works via something else).

I have added a port for cups now: https://github.com/macos-powerpc/powerpc-ports/commit/64fd093a3983684cd2f084be78a42ad09fe95711

 

[Forest Expertise]

I think you do not need to install the app, mpkg and mdmg should work without that. (Ports which I use to build system components explicitly prohibit installing them directly, for example.)

You are correct mpkg and mdmg should work without installing first. Installing does let you test if stuff is working before making the dmg, which is probably why I got into the habit of it.

I was asking to gain a better understanding of what the possibilities are at this stage, and graciously, thanks to your explanations and @Forest Expertise, I as well as anyone else reading the thread are now more informed.

Considering the availability of Finder, the only utility in PCManFM in particular (that I can think of) is if it can be paired with libimobiledevice to enable file transfer with modern iOS devices as--unless I am mistaken--I can't imagine that libimobiledevice (and similar active libraries if any) would be able to talk directly with Finder instead out-of-the-box... unless perhaps using Xcode they were installed into a new kext or framework that could serve as a shim interface between them and Finder, supplanting the need for a second file manager. But that is another project not quite on my screen at the moment.



If nothing else, perhaps it could just walk the user through the installation process using normal language. As in, it announces what it's going to do next, requests permission for each stage, and executes the steps behind the scenes while the user keeps clicking "Continue" to run successive commands.

Further still, maybe after it finishes setting up the development environment, it can display a list of selections of working software for the OS it's being run on, then proceed to download the materials for the selected application(s), run a build, and then automatically deposit the finished binary into /Applications. Very similar in design to tasksel during the installation of a Debian system.

If people would like better access to modern software on OS X, I think such a device would dramatically improve ease of use for sure.

Another thought - if you mdmg a port with enough dependencies as described above, you can have a massive amount of software included with one install. For example, the claws-mail installer I made provides curl and python313, which can both be used independently as well. On thinking more about this, it may be possible to install PPCPorts from source into /opt/allawesomesoftware and then make a metaport which depends on all the software you want to provide. Then sudo port mdmg metaport might give an application that provides a lot of useful software. @barracuda156 how feasible would making such a metaport so only one installer is needed be?

 

[barracuda156]

@barracuda156 how feasible would making such a metaport so only one installer is needed be?

If you mean how you or someone else may do it, then, I guess, add a stub port like done for CRAN recommended packages, as an example. You can make it depend on arbitrary ports and produce an installer for all those.

I don’t like the idea myself, but there are no objections for someone else doing it.

IMO, there are two scenarios where it makes sense: 1) toolchain; 2) replacement of system components missing or defunct in a given system (think curl or git). What is the minimally required toolchain and “complete” one is well-enough defined: there is no question of some user wanting to install nm but not ar LOL. How it will be handled for some arbitrary set of apps? Also, does it really make life easier than installing pre-built packages?

 

[Forest Expertise]

If you mean how you or someone else may do it, then, I guess, add a stub port like done for CRAN recommended packages, as an example. You can make it depend on arbitrary ports and produce an installer for all those.

I don’t like the idea myself, but there are no objections for someone else doing it.

IMO, there are two scenarios where it makes sense: 1) toolchain; 2) replacement of system components missing or defunct in a given system (think curl or git). What is the minimally required toolchain and “complete” one is well-enough defined: there is no question of some user wanting to install nm but not ar LOL. How it will be handled for some arbitrary set of apps? Also, does it really make life easier than installing pre-built packages?

Thank you for providing an example of such a stub metaport!
I think it makes sense when the size of the apps one is interested in is less than the size of Xcode (up to 2 GB of software, roughly). Then you are saving a not insignificant amount of disc space on some of these original hard drives. I agree that curl and git are great examples of what could be included in such a metaport. And with pre built packages you have to rely on a server being up - my pre built packages are on a server that can't handle many simultaneous requests and is hosted over wifi, so it isn't the most reliable (but it is very cheap for me to host, which was my criteria). The server also has to be up to date, which you do a phenomenal job of with 10.6.8 but isn't as likely on other OS. For example, you have mentioned that ppc64 Leopard packages are not up to date (is this still true?), and I recall Matias builds for 32 bit on Leopard. So at a minimum, ppc64 Leopard would benefit from this approach as there are not very current pre built binaries.
It's not a priority, but it has legitimate use cases.

 

[barracuda156]

Thank you for providing an example of such a stub metaport!
I think it makes sense when the size of the apps one is interested in is less than the size of Xcode (up to 2 GB of software, roughly). Then you are saving a not insignificant amount of disc space on some of these original hard drives. I agree that curl and git are great examples of what could be included in such a metaport. And with pre built packages you have to rely on a server being up - my pre built packages are on a server that can't handle many simultaneous requests and is hosted over wifi, so it isn't the most reliable (but it is very cheap for me to host, which was my criteria). The server also has to be up to date, which you do a phenomenal job of with 10.6.8 but isn't as likely on other OS. For example, you have mentioned that ppc64 Leopard packages are not up to date (is this still true?), and I recall Matias builds for 32 bit on Leopard. So at a minimum, ppc64 Leopard would benefit from this approach as there are not very current pre built binaries.
It's not a priority, but it has legitimate use cases.

Yeah, it is understandable that in some circumstances downloading may be easier (though installers, likewise, must be hosted somewhere). I just don’t understand how it can work for ports in a sensible way. (There is no argument that it can work for some very specific isolated thing demanded by many users.)

There are several thousands of ports. We would need to somehow guess what users want of that, at the same time minimizing installers size (no one will be happy to download 10 GB dmg for a 100 KB app). That must install into some location, not conflicting both with ports and stuff in user directory. Then, it is clearly impossible to have a single installer, otherwise it either gets ridiculously huge or cannot possibly include every app someone would want. So we will need multiple installers. Say, I want apps A and B. I will need to somehow find out whether they exist in some installer and if yes, which one specifically. Assume they happen to be in two different installers. Those either need to install in non-conflicting locations or will have conflicting components (each installer will need to have a set of basic typical dependencies like openssl and python). In result I need to a) effectively download same stuff multiple times, b) either waste disk space on separate installations or figure out which components to need to install and which to disable, c) assuming I do not want to download gigabytes of dmgs every time I need to re-install system, I also need to somehow keep a track of which app is where (in local copies of installers), or otherwise search for them every time. Now consider that installers are prepared in a given moment of time (it is like a snapshot of a subset of ports). Since they won’t be regenerated on every commit, at any given moment we can have installers with incompatible versions of libraries. So if someone suggests that “we can just overwrite older stuff with newer stuff, when using another installer”, no, that won’t work, because if something is built against an older dylib and you update that dylib, that thing can be broken and refuse to launch. Now consider this whole scenario from a point of view of a maintainer (or just someone trying to help someone else on a forum here). How to debug it? With ports you can a) always see the current state of code, b) always reproduce deterministic bugs, c) fix bugs once they are discovered and update ports, which in turn fixes those for end-users. What am I supposed to do if someone says some app is broken, being installed from one of multiple incoherent installers? It is not even possible to understand what environment a given user has (at least without analysis of all that mess). Say, you figure out what is wrong. How to fix it for a user?

 

[barracuda156]

@Forest Expertise If the problem is framed to be about a given single app, it seems natural to say “why bother with ports, make a dmg of a version confirmed to work, anyone installs it, it always works”. And this makes sense for a single app (or a fixed subset of apps, like Unix tools which work together and need to be used as a combo). But we do not have a scenario where everyone wants a single specific app.

 

[srp]

This is why I bundle all of the dependencies with the apps I release, and build statically wherever it's feasible.

a single specific app.

This was sort of the idea with AquaCenter - one runtime and frontend for a bunch of different media related dependencies.

 

[barracuda156]

I think if an actual unified installer was provided to install xtools, make, curl, etc in one go so that setup is just a matter of grabbing Xcode and running the installer

That is doable, though I am not sure if that significantly changes anything. After all, people normally – forget old macOS and ports – install apps separately.
We can probably have a combo version though in addition to separate installers (there is a benefit in having separate ones: Unix tools are not updated often, and it is not desirable to change them often, while something like curl can follow actual releases schedule).

more support / resources were provided for 10.5 rather than 10.6 (wherever possible) because that is what most people are using

I guess you know my opinion here: if they are, they should rather switch to 10.6 wherever possible, but you are right, it will be nice. I just don’t realistically have time for more than one OS. Both in a sense of my personal time and in a sense of hardware used to compile stuff.

and that the project was also marketed more effectively to communicate the new advancements it provides and how it also democratizes the software development process by now making it available to anyone (or something like that), then I'm sure it would catch on much faster since most would probably appreciate the ability to easily assemble something themselves instead of waiting for someone better equipped to do it. Ergo, more people benefit from these projects by building software that they wouldn't have otherwise; just look at the recent explosion of vibe coding of this phenomenon in practice.

You have to meet folks where they are, and while there is a lot of hobbyist / enthusiast traffic here, only a portion seem to have the developer mindset that would naturally predispose them to benefiting from these tools (and of course there is nothing wrong with that). But if the above improvements were made for example, PPCPorts could easily be plastered onto the front page in the Sorbet App Store, written in news articles, and featured in videos for the average user to get involved with because the barriers to entry would be even further lowered and inherent value clearly communicated. Then no doubt a lot more would be aware of what we have.

But now I am thinking out loud again. They are all just ideas, I suppose...

I agree with you, I am just bad at marketing anything (and don’t enjoy doing it), and I guess nobody else was motivated to do it either, so we have what we have.

 

[barracuda156]

This is why I bundle all of the dependencies with the apps I release, and build statically wherever it's feasible.
This was sort of the idea with AquaCenter - one runtime and frontend for a bunch of different media related dependencies.

That’s perfectly reasonable for a single app. Especially stuff like media center or a web browser. Not so much for multitude of diverse apps though.

 

[srp]

That’s perfectly reasonable for a single app. Especially stuff like media center or a web browser. Not so much for multitude of diverse apps though.

I think for a lot of the gtk ports you've been working on this would be useful as well. Transmission, Filezilla, Claws-mail, QMPlay2. I generally prefer having a bundled .app in a dmg which I can drag into my Applications folder - but you could install CLI utils like Git via a pkg.

Most people just want a list of usable software ready to go with the related installers. To avoid conflicts, we could set these packages up to install into a separate prefix like /opt/packages. I wonder how difficult it would be to create a precommit hook that automatically cuts a .dmg/pkg release when you go to push a port update (or some other similar mechanism) so that this is mostly a hands-off process.