One of the challenges of developing RPMint is rebuilding all of the packages using a modern compiler. Sparemint was built with gcc 2.95.3 almost exclusively which is incredibly dated. We are on GCC version 7 now! Unfortunately for ease of use, building software for the coldfire variant is going to require GCC 4.x at minimum.
Often rebuilding an older package with a newer compiler exposes source code errors or incompatibilities. The typical path is... upgrade your compiler, upgrade your package. Sometimes newer packages change entirely how they work, even their names. This means that the initial build of each package will require a whole new round of changes, patching and testing to get moving. We've made good progress on this. The results can be found here http://storage.atari-source.org/atari/personal/coldfire_packages/ with brand new ports including coreutils, procps-ng, shadow and more.
Part of the goals of this system is the move from a hand built hand architected system to a system that has all of the dependencies known and carefully specified. Such a thing would make it so that the system can automatically query what packages it needs to build and in what order. The two fun discoveries that lead to this post are graphviz and repoquery. The former allows you to create a simple chart of dependencies in text and render it in a graphical format. Convenient!
Alas evaluating dependencies still requires you to carefully examine the build output to look for libraries and things the configure script is looking for as well as what is built in. Not to mention what language the package is compiled in and more. It occurred to me though that all modern distributions autobuild and would have to go through the same thing so some useful tools might already be present on my fedora box. And indeed I wasn't disappointed. The first scenario is to find out what packages may depend on a particular package. For instance, zlib is a library that may be linked into many other tools. tar for instance would use the linked in zlib when specifying the "z" option. If you didn't link it in, then that mostly standard option wouldn't be available. Similarly git might link openssl. If it misses that option, it may still work but it may not be able to communicate to an https web server. Also a fairly standard option these days. The fact is for the most part you'd want these packages to work how they would on a modern linux system, and so looking at the dependencies on these systems will get you close. That command is:
dnf repoquery --whatrequires "packagename"
And in response you'll get a list of all the packages that require zlib as they are setup. Pretty useful to double check my work. Also interesting is:
dnf repoquery --requires "packagename"
In the instance of running this against git you get:
/bin/sh
/usr/bin/perl
emacs-filesystem >= 25.2
emacs-filesystem >= 25.3
git-core = 2.13.0-2.fc26
git-core = 2.13.6-2.fc26
git-core-doc = 2.13.0-2.fc26
git-core-doc = 2.13.6-2.fc26
libc.so.6(GLIBC_2.14)(64bit)
libgio-2.0.so.0()(64bit)
libglib-2.0.so.0()(64bit)
libgobject-2.0.so.0()(64bit)
libpcre.so.1()(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libpthread.so.0(GLIBC_2.3.2)(64bit)
librt.so.1()(64bit)
librt.so.1(GLIBC_2.2.5)(64bit)
libsecret-1.so.0()(64bit)
libz.so.1()(64bit)
libz.so.1(ZLIB_1.2.0)(64bit)
perl(:VERSION) >= 5.8.0
perl(Error)
perl(File::Basename)
perl(File::Find)
perl(File::Spec)
perl(Getopt::Long)
perl(Git)
perl(Git::I18N)
perl(Term::ReadKey)
perl(lib)
perl(strict)
perl(warnings)
perl-Git = 2.13.0-2.fc26
perl-Git = 2.13.6-2.fc26
rtld(GNU_HASH)
Pretty neat that you can see right down to the individual perl modules you'll need to build the perl portions of Git. Will all of these dependencies make it through to rpmint? Maybe not at first, but there is no harm in someone would like to see them submitting a revised spec that pulls in the dependency and builds the package linking in support for it. The neat thing is that if the dependencies are well specified the package can be rebuilt automatically for all supported platforms and importantly, all packages that depend on or link to the particular package can be automatically detected, rebuilt and bumped a release version.