Changes

====Clamav packages.====

====Clamav packages.====

This is a special case. Whilst not build by SME, and due to problem having been experienced in the past, these packages (three of them) are attached to a single SME bug in bugzilla. There is no specific changelog. However, verification is recommended before release.  

This is a special case. Whilst not build by SME, and due to problem having been experienced in the past, these packages (three of them) are attached to a single SME bug in bugzilla. There is no specific changelog, however verification is recommended before release.  

====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==

==BUILD SYSTEM==

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.

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:

An automated email is also generated:

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.

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).

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 [SME Server:Documentation:Developers Manual:Section3]).

Each repository has a max number of versions and releases that it can contain.  Most by default are set to 1 for both values.  The exceptions are smetest that has versions = 2 and release = 3 and smeupdates-testing which has version = 1 and release = 3.  It means that the test repo can have two different version streams (devel and prod) as well as several releases on each version.

Each repository has a max number of versions and releases that it can contain.  Most by default are set to 1 for both values.  The exceptions are smetest that has versions = 2 and release = 3 and smeupdates-testing which has version = 1 and release = 3.  It means that the test repo can have two different version streams (devel and prod) as well as several releases on each version.