ghost
commented
11 years ago The value / weight passed to the client can be passed to sbuild to bump the changelog inside the binary package, not the source package. Note that the user recorded in the internal changelog must be specified to sbuild and should be an arbitrary / group email related to the supported clients.
sbuild -m "Client <client@example.org>" -A -d suite --append-to-version ".1" foo_0.0.41.dsc
This will result in a .changes file which only refers to the binary package - no source will be uploaded.
The name of the changes file will reflect the version appended:
foo_0.0.41.1_i386.changes
The result of this is that the weight pushes the binary package built in the weighted environment to a higher version string than the unweighted upload.
If the unweighted suite is unstable and the weighted suite is experimental, the same source package could build foo using foo_0.1.2.dsc, upload foo_0.1.2_i386.changes to unstable and foo_0.1.2.1_i386.changes to experimental.
The intention is to allow source code to be tested against new releases of base software ahead of a full migration of the codebase and build chroots to the new base.
When a decision is made to migrate to the new base, the packages with the appended versions can be migrated into the main repository, upgrading all the packages to the new base.
If we extend db, controller and model to incorporate a weight value for each build environment, we should be able to define a 'priority' for multiplexed job based on this build environment weight.
This value will also be recorded in the packageinstance object (and therefore the jobrequest message that the client processes. The client could then 'use' this value for package upload, enabling us to upgrade between build environment.