My main goal in looking for something like this is avoid hand building + re-building when bugs get fixed. chroot or otherwise is a choice of the tool.
"didbs" currently rolls + builds about 90 packages (and that will grow) - and the order the packages get built is important - and that's the same for rpms too. I'd like to avoid the situation seen with nekoware where someone updates one package and the "down stream" things that depend on that package are now broken because there was no way to know they needed rebuilding.
Without some automated tool - we're looking at re-rolling something to extract the dependencies and calculate the appropriate build order (a "dependency" engine) and reverse dependency rebuilding on updates.
I'd like to avoid maintaining any code for that (the sooner didbs dies, the better) - either mine or anyone elses.
IRIX RPM based tool chain and platform. Contribute to danielhams/didbsng development by creating an account on GitHub.
The idea is to replicate a platform equivalent to "didbs" - but using rpm. It is a work in progress with much to do.
Q) Why isn't this already `/usr/sgug`
A) There's going to be many bugs in the release, issues about where the content gets hosted, how we distributed stuff. All of these questions are not the goal of "didbsng" - it is purely to work on the `.spec` files necessary to create an equivalent toolchain to didbs.
Contributions are _more_ than welcome. It's rather raw for the moment, and my criteria so far is "does it build".
Idea is to get all the pieces in the didbs chain "compiling" - and afterwards the actual package dependencies are activated.
At that point, it should be possible to take a snapshot of some initial filesystem state and create a `.tardist`. We have a bootstrap.
Get spec files building for things on the toolchain
Ensure any needed patches from didbs are moved over
Rebuild all the `.rpm`s within the new root
Re-enable the dependencies
Rebuild again, checking all is well
`make check` all the packages
Snapshot of the filesystem at this point as a tarball for testing
Once we get to that stage, it's perhaps time to rebuild move everything to `/usr/sgug` - and begin discussions about build infra, where/how these packages are hosted - and what kind of "front end" we want to put in place (e.g. something akin to "yum" would be nice).
If you're contributing - perhaps it useful to add a post here with what you are currently working on and keep it updated, so we're not burning time working on the same thing.