Christian Faulhammer

und seine kleine Welt

  • Schrift vergrößern
  • Standard-Schriftgröße
  • Schriftgröße verkleinern
Home Archiv Gentoo Architecture work the way I do it

Architecture work the way I do it

E-Mail PDF

Every one of us dumb workhorses called architecture developers has its own way of scripting all the commands necessary to stabilise/test a package on its architecture, but I would like to describe how I do it, for the curious. The bug list of the architecture (x86 in my case) with all keywording and stabilisation requests is the starting point here.

Normally I install the packages in a chroot and I follow the never-uninstall-a-package policy to catch file collisions, while others keep the system lean to find missing dependencies (they probably use the buildpkg feature of Portage to keep compile times for dependencies down). To put all needed packages in the package.keywords file, I use the Gentoo Arch Testing Tool (app-portage/gatt) which does that automatically. Compile test includes up to three runs: With all USE flags enabled, then all disabled and then finally what make.conf and the profile defines. The last iteration is then tested, either by starting the program and using it for some time (games usually get a longer testing period) or by building packages that depend upon the package to be stabilised. I have a little script that extracts that information from the tinderbox' rindex and determines which package is in stable and needs to be rebuilt. Manual work includes a short glance if USE flags are needed to activate the support for that package. Installing as most depending packages as possible makes sure all reverse dependencies still build, this sometimes leads to other stabilisation requests or bug reports blocking the stabilisation of the initial package.

After everything went successfully I tell Gatt to create a script in the /tmp/ directory which is shared with my main system. From there I call that script which is quite capable and there is an extensive manual for it.

That's how your package hits stable on x86 usually. Big things like KDE or Gnome are handled differently, the script is shorter:

  • Install it with the package list provided by the team (normally that's the case)
  • Test it
  • Keyword all packages and add ChangeLog entries (without commit)
  • Run QA checks with repoman over the whole category
  • Run commit with --force to disable QA checks to speed up process (it still takes hours for KDE)

Kommentare

B
i
u
Quote
Code
List
List item
URL
Name *
URL
Code   
ChronoComments by Joomla Professional Solutions
Kommentar abschicken