Once upon a time there was Sparemint. A term used to collectively describe a group of RPM packages for FreeMiNT. RPM packages - for those that don’t know - are basically just software archives like a zip file with a bit of metadata built in. More importantly the system includes instructions and patches for compiling.
Sparemint isn’t gone since what was built still exists and all.. But the domain no longer points at a valid website and nobody really controls it or maintains it. Especially nobody steers it. Once upon a time Sparemint really was enough. These days however the picture of the Atari world is a little more complicated. You have coldfire based machines and those machines are simply not compatible with 68k machines (even though they’re pretty close). While you may be able to load FireTOS and through the miracles of emulation run all of the existing packages, you do it with a huge speed penalty. Several packages in sparemint contain 68030+ only code in them. The operating theory at the time was sound - no 68000 machine could have more than 4MB of memory and thus it was nonsensical to try to use the unix packages. Bash alone consumes 1MB of RAM. But these days the situation is far more complicated. With the MiST board, you can have an ST style machine with 14MB of RAM. With the MonSTer board many people are flying around with 12MB ST’s. These unix packages are no longer maniacal… Instead just a little crazy.
One thing that always annoyed me about sparemint is that the build dependencies aren’t well thought out or specified. Indeed I’m not sure RPM is really capable by itself of dealing with the limitations of static linking. You see on our platform all binaries have all library code linked in at compile time. What this means is say you build openssl. You then build wget, links, and a few other programs that link to openssl. Then you find there is some type of bug in openssl. On a system with dynamic libraries, you could simply rebuild the openssl library with the bugfixed version. As long as it maintains the same ABI, the linked programs would run utilizing the new code. Not with our system. I always felt it would be a good idea to improve sparemint to automatically rebuild dependent packages. Static linking doesn’t really harm us much then.
And so I bought rpmint.com and intend to build a new alternative to sparemint. Make no mistake, this will be almost exactly like Sparemint. I pretty much like Sparemint as it is, and I like RPM. The difference is that packages will get updated with new ports and new ways of doing things. I’m going to try to improve the init scripts a bit, perhaps with an optional monolithic compiled single startup application. I’ll have 3 different builds of each package, 68000, 68020-60 and coldfire. There will be a comprehensive website with package info and searching, as well as a simple community based approval system. Git will be the data backend when it makes sense. There will be a combination graphical and CLI update client to run on end user machines. There will be a build farm on the backend that automatically recompiles software as necessary.
That’s what it is. What it isn’t? It is not a complete MiNT system, like you would get after installing Linux. This is the unix software you would generally install on an ext2 partition. Typically command line, but not always. Basically none of the packages I will create will touch C:. Nothing to maintain the auto folder, nothing to install a new MiNT kernel, and nothing to install XaAES. The reason is that there are so many different systems and setups that I feel this is an almost scary moving target. Secondly that particular problem is nearly identical whether or not you want to use unix ports or whether you just want to boot into an AES and run GEM only apps. Perhaps some day we can get to that, but in all honesty the goals are already super ambitious and super vaporware.
Right now the domain is registered. The codebase for the website has been started. Since my Firebee is dead, I’ve managed to get an M5484LITE board running with FreeMiNT and this system will serve as the coldfire backend build system. I have two Aranym instances setup for the other two build systems. I have perhaps half of Sparemint updated and built for coldfire. These packages should rebuild with no changes for 68000 and 68020-60. There is much work to do, including defining a minimal bootstrap for a build system and establishing what interdependencies it has. Then establishing the library and operational dependencies between all the rest of the packages. Then rebuilding all the RPM’s to contain this dependency info. Then creating the automated systems to actually do this rebuilding. Then building up the website around all of this backend work. The very first product you will see is a whole lot of RPM packages. We’ll see how this all goes, but that’s the goal. Wish me luck!