1,574
edits
Changes
Jump to navigation
Jump to search
Line 25:
Line 25: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
no edit summary
-Contribs.
-Contribs.
Not part of the updatesteam maintenance cycle. Verification and release are managed by individual maintainers. However, contribs packages are created in smetest, then moved direct to smecontribs - they do not appear in smeupdates-testing.
Not part of the updatesteam maintenance cycle. Verification and release are managed by individual maintainers. However, contribs packages are created in smetest, then moved direct to smecontribs - they do not appear in smeupdates-testing.
==BUILD SYSTEM==
The build system generates automatically all categories of packages by means of a script developed by Shad Lords. The script looks for all packages in higher level repos (contribs, updates, os, extras, etc) and checks for newer version in centos, epel, atrpms, rpmforge, buildsys. If it finds a newer version then it will automatically move it to the smetest repo. This is where developers/contributors should look for possible updates. No checking has been done at this point and quiet often the packages pulled automatically aren't fully compatible.
In most instances, the script will see newly built packages and put them in smetest automatically. All transaction are the subject of a repository update email (from releases@contribs.org) to the updatesteam list. For example, as soon as a new tzdata package from centos becomes available for sme8, the new package is dropped into smetest.
An automated email is also generated:
Subject:[updatesteam] Repository Update
Date: Mon, 26 Nov 2012 10:47:31 -0700
From: releases@contribs.org (Releases)
To: updatesteam@lists.contribs.org
tzdata (sme8)
=============
copy from centos to smetest (tzdata-2012i-2.el5.i386.rpm)
copy from centos to smetest (tzdata-2012i-2.el5.src.rpm)
copy from centos to smetest (tzdata-2012i-2.el5.x86_64.rpm)
rebuild repo (sme8)
===================
rebuild smetest/i386
rebuild smetest/x86_64
_______________________________________________
SME Server maintenance team internal discussion
To unsubscribe, e-mail updatesteam-unsubscribe@lists.contribs.org
Searchable archive at http://lists.contribs.org/mailman/private/updatesteam/
However, if the build system has never seen a package before, the package will end up in smedev instead of smetest. Smedev is where all first time built packages end up. It is also where all the extra packages that come out of a build end up if we don't use them. An example is php. We don't use all the packages that come out of the php srpm. The ones we don't use end up in smedev while the rest that we do would progress from smetest -> smeupdates-testing -> smeupdates -> smeos. Smetest and smedev are basically on the same level but are separate so the developers don't have to sift through all the unwanted/unneeded packages. If a package becomes wanted or needed then move it from smedev to smetest.
All packages we know about are checked. If a developer adds a new dependency that we haven't seen before, then the developer will need to manually scp the file into smetest on first use for it to be processed and added to the distro. After that the script will check for newer/updated versions and drop them automatically in smetest whenever a new version is available. To build a package (the buildsys will choose itself where it goes) simply send the build command from your environement (see the wiki page for package build).
Smetest can have multiple versions of a package, maybe the three newest. I am not aware whether they are archived. As they are built from CVS it should be possible to recreate one if really needed.
When the developer is satisfied that a package won't break the system and wants wider testing without actually releasing things, the package should be moved manually into smeupdates-testing. This is a semi-stable testing area that shouldn't break a system but hasn't been verified yet. This repo is also included in Shad's staging area (stage) for the purpose of building the next ISO. All verifications should be done on packages in smeupdates-testing. Once the package is verified, and agreement reached on the Go/NoGo for releasing, the package should be copied manually to smeupdates and released.