Git, Gitlab, and More, Oh My

Interesting updates for today.

Despite all the humming and hawing, at the convincing of one of one of surro’s designated greybeards, we’re going to try to go with RPM for the package manager after all.

This was not without thought.

The distro goal is LSB 5 certification, FHS 3 certification for the purpose of being a very compatible distribution.

That said, going with RPM is actually a pretty significant power play.  It’ll allow us to natively ingest packages from other distributions that are RPM based once they catch up on the LSB frontier.  And, technically, it’s required by the LSB to either have RPM or something that will convert RPM to the native package format of the system, so it avoids me having to implement an RPM repackager.  So there’s a lazy factor, too.

On top of that, pacman is, like much of what we’re seeing in Arch Linux, relatively unpolished.  For those arch users reading and chewing on that, I just want to ask two questions:

  • Are your binary packages peer reviewed?
  • Are you able to have multiple kernels installed at once without tricking your package manager?

Maybe I have mis-evaluated and just don’t know — I wasn’t able to determine that either were the case.  Moving on, there are two new public services launched:

git.luxidolon.com

A new gitlab instance for Surro Linux as well as a git server for all of our committing and pushing needs.

repo.luxidolon.com

A simple apache2 instance for initial RPM and SRPM hosting.

The purpose of hosting them on another domain is for my own sanity.  I’m wanting to keep all of the platforms involved in this relatively separate from each other by task type.

 

Directory Hiearchy and Naming Convention Determinations

 

RPM REPO:

SRPMs

${dist}/${arch}/${category}/${pkg_name}-{$version}.src.rpm

RPMs

${dist}/${arch}/${category}/${pkg_name}-{$version}-${arch}.rpm

 

GIT REPO:

SRPMs

${dist}/${arch}/${category}/${pkg_name}-${version}

 

A word on build systems.

It is not yet set in stone, but there are talks of having koji as a build system so that we can utilize mock, the wonderful chrooty thing that Fedora uses to build clean packages.  This will depend on what I find out integration with gitlab will look like with it.  Ideally, a push to an SRPM GIT REPO mentioned above would trigger a build system to generate the rpm and srpm that ends up in the RPM REPO also mentioned above.