[Launchpad Wiki] Update of "Soyuz/NativeSourceSyncing" by CelsoProvidelo
Launchpad Wiki
webmaster at ubuntu.com
Tue Feb 27 19:28:32 GMT 2007
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Launchpad Wiki" for change notification.
The following page has been changed by CelsoProvidelo:
https://launchpad.canonical.com/Soyuz/NativeSourceSyncing
The comment on the change is:
changing basic directions
------------------------------------------------------------------------------
== Use cases ==
- * Colin is processing an update to dapper submitted by a developer, which has gone through testing in the PROPOSED pocket as specified in the [http://wiki.ubuntu.com/StableReleaseUpdates Ubuntu stable release updates process]. He wishes to transfer this update directly into the UPDATES pocket without the need for a rebuild. He finds the version he wishes to migrate, builds an appropriate changesfile and upload to ''upload.ubuntu.com''.
-
- * Scott wants to migrate a Debian source package to the current development Ubuntu release (currently handled by sync-source). He buids a changesfile targeted to 'ubuntu/feisty' and uploads to ''upload.ubuntu.com''
+ * Colin is processing an update to dapper submitted by a developer, which has gone through testing in the PROPOSED pocket as specified in the [http://wiki.ubuntu.com/StableReleaseUpdates Ubuntu stable release updates process]. He wishes to transfer this update directly into the UPDATES pocket without the need for a rebuild.
+ * Scott wants to migrate a Debian source package to the current development Ubuntu release (currently handled by sync-source).
+ * Fabio wants to include one of the packages published in his PPA to ubuntu/feisty without the need for a rebuild.
+ * Raphael is a REVU member and does not have access to production system, but he wants to sync one of his PPA package to ubuntu/feisty. He can use either the restricted WEB UI or the XMLRPC client tool for it.
== Assumptions ==
+ None.
- * NascentUpload code cleanup (nascentupload-cataclysm)
- * Distro team will develop and release tools to help maintainers to write proper sync changesfiles.
== Design ==
- The NSS procedure will be entirely based on the current upload system, no extra infrastructure parts will be required, while it allow decentralised (developer-centric) syncs workflow.
+ The NSS procedure will be entirely based on the current publishing system, no extra infrastructure parts will be required.
- The current lookup mechanism in NascentUpload will be modified to localize the right references for claimed files across distributions.
+ It will be deployed in the following steps:
- Once the respective SourcePackageRelease and/or Build and BinaryPackageRelease were localized and verified for sanity (see below) the upload will be submitted to the already existent queue processing cycle (NEW/UNAPPROVED, ACCEPTED/REJECTED, DONE).
+ 1. a command line tool on a machine with db access, limited to archive-admins
+ 1. a web ui, that lets appropriate people say "move X to Y"
+ 1. an xml-rpc version of the command-line client tool which can be given to a wider group of users
+ Each request will be verified for sanity (see below) and submitted to the already existent queue processing cycle (NEW/UNAPPROVED, ACCEPTED/REJECTED, DONE).
- Sync uploads will be also subjected to the same rights the uploaders already have for normal uploads.
+ Sync uploads will be also subjected to the same rights the requesters have for normal uploads.
== Implementation ==
Based on design requirements above we can highlight the following implementation details:
- * The changesfile parser should be modified to understand "Distribution:" field values as "<DISTRIBUTIONNAME>/<SUITENAME>", with fallback to 'ubuntu'
- * File lookup should consider every files ever published in all distribution present in Soyuz, by querying (MD5, filename)
+ * DistroReleaseQueue creation should not require a changesfiles.
+ * We will land an enhanced pre-publication override layer (required for debian syncs)
+ * Source syncs can optionally carry their binary.
* Synced binaries will preserve the original build information.
- * Reference entities will be verified for sanity:
+ * Reference entities will be verified for sanity during Queue.accept()
* Claimed sources files match found SourcePackageRelease,
* Claimed SourcePackageRelease matches claimed BinaryPackageRelease,
* All BinaryPackageRelease generated by the found Build are included
* ...
- * Target sources/binaries will be assumed as trusted code and won't be verified again (OPTIONAL)
- * We will land an enhanced pre-publication override system (OPTIONAL, required for debian syncs)
=== UI Changes ===
- No UI changes are required.
+ ==== Command-line script ====
+
+ The command-line tool should be based on LaunchpadScript infrastructure and respect the following format:
+
+ {{{
+ $ package-sync.py [-c COMPONENT>] [-s SECTION] [-b] <SRCPATH> <DESTPATH>
+
+ -c COMPONENT -> source target component name
+
+ -s SECTION -> source target section name
+
+ -b -> include or not binaries
+
+ SRCPATH -> /~<USER>/<ARCHIVE>/<DISTRO>/<SUITE>/<SOURCE>/<VERSION>
+ where:
+ * USER/ARCHIVE defaults to None (main distro, not a PPA)
+ * DISTRO default to 'ubuntu'
+ * SUITE default to current distrorelease and pocket RELEASE
+
+ DESTPATH -> same as SRCPATH
+ }}}
+
+ CelsoProvidelo: I don't know if 'prompting for binary overrides' when required would be a good solution here.
+
+ ==== Launchpad Web UI ====
+
+ It will require a page on DistroReleaseSourcePackageRelease (ubuntu/feisty/+source/foo/1.0) allowed only for restricted group.
+ Via that pages the user will be able to select:
+ * Targeted suite name & archive given by a vocabulary
+ * Target component & section (respecting the selected suite)
+ * Whether or not the resulting binaries should be included
+ * component, section and priority for each resulting binary.
+
+ CelsoProvidelo: Pending mockup.
+
+ ==== Launchpad XMLRPC script ====
+
+ Should be similar to the local command-line tool.
=== Code Changes ===
- * NascentUpload code will be modified to perform the specified tasks in conjunction with `nascentupload-cataclysm` branch.
- * DRQS/DRQB.publish should be aware of the annotated overrides when creating a new SSPPH/SBPPH records (see Schema Changes)
+ ==== Pre-Publication Overrides ====
+
+ Currently pre-publication overrides are done by modifying the original Component Section/Priority in the SPR/BPR record, which is wrong and wouldn't work properly for derivation. One solution would be create an new annotation table to store pre-publication overrides:
+
+ {IDistroReleaseQueueSource, IDistroReleaseQueueBuild}.publish should be aware of the annotated overrides when creating a new SSPPH/SBPPH records
+
=== Schema Changes ===
+ DistroReleaseQueue.changesfile should be modified to allow empty values. This change will have implication in the SPR.changesfiles and related.
- Currently pre-publication overrides are done by modifying the original Component Section/Priority in the SPR/BPR record, which is wrong and wouldn't work properly for derivation. One solution would be create an new annotation table to store pre-publication overrides:
-
Each BinaryPackageRelease generated by an binary upload would be overridden according the following table.
-
{{{
DRQBOverride(
DRQB FK,
@@ -74, +115 @@
priority dbschema,
)
}}}
-
Pre-publication source overrides can be collapsed in DistroreleaseQueueSource table if necessary:
-
{{{
DRQSOverride(
DRQS FK,
@@ -94, +133 @@
* CelsoProvidelo: The new pre-publication overrides system isn't really required for having NSS inside ubuntu, where the auto-overrides will work perfectly well. However they are necessary for debian syncs, other wise we will end up trying to publish stuff to un-selected components in ubuntu. Nonetheless I'd recommend to delay this implementation until we have landed PPA code (which renames and modifies the queue tables badly).
-
----
CategoryProposal
More information about the ubuntu-archive
mailing list