rpm 4.15.0

hammy

Member
Jun 1, 2019
65
32
18
UK
Edit: See down below, more recent developments make this initial post redundant.
 
Last edited:
  • Like
Reactions: Elf

Elf

Storybook
Feb 4, 2019
87
14
8
Interesting; I haven't used build systems like this before, I have always just hand crafted the RPMs (which of course is probably not the best way to go).

Is the main purpose to do an install in a chroot'd environment so that it can keep track of what to put in the install manifest?
 

hammy

Member
Jun 1, 2019
65
32
18
UK
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.
 

hammy

Member
Jun 1, 2019
65
32
18
UK
There is now the "didbsng" project on github here:


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.
 
  • Like
Reactions: Elf

Elf

Storybook
Feb 4, 2019
87
14
8
Very cool. I swear, you are close to pulling me in on the software side once I get a few other SGI related things out of the way :)
 

hammy

Member
Jun 1, 2019
65
32
18
UK
And here's where the status of these packages can be tracked visually (ish).

Steps going forwards are:

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.
 
  • Like
Reactions: Elf

About us

  • Silicon Graphics User Group (SGUG) is a community for users, developers, and admirers of Silicon Graphics (SGI) products. We aim to be a friendly hobbyist community for discussing all aspects of SGIs, including use, software development, the IRIX Operating System, and troubleshooting, as well as facilitating hardware exchange.

User Menu