Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

UMD REPO Team Issues

From EGIWiki
Revision as of 10:59, 16 October 2012 by Krakow (talk | contribs)
Jump to navigation Jump to search

Based on the CAs exercise, a couple of YUM/APT related issues came up to me that need to be clarified:

First of all, there are three "types" of releases identified until now:

  • A. Delta release (only diffs - to the end): a release that it populated "as is" in the stage-rollout and in the production repo. (egi-CAs case)
  • B. Semi-Delta release: a release that it is populated "as is" in the stage-rollout ***but*** it should be appended to the rest of the bundle in the production repo. (gLite case)
  • C. Typical release: a release that it contains the (base)+(the updates) and be populated "as is" in both the stage-rollout and in production repositories. (a Typical case!!!)


Concerning the YUM/APT repos (re)creation

We see two cases:

Case A & C: no special actions have to be performed by the Repository respectively to the YUM/APT repositories creation. If the SW provider includes the repodata folder(s) in the bundle, then the SW will be provided by the Repository, in a YUM and/or APT form. The only action that actually has to be made by the Repository is to change the "baseurl" value withn the given (by the SW provider) .repo files. NOTE: In case "we" want the rpms/deb to be digital signed, the repodata/Packages.gz should be recreated (overwriting the ones that SW provider provided).

  • Case B: For including the release in the stage-rollout repo, no special actions have to be performed by the Repository respectively to the YUM/APT creation.

But, when the release goes into production repo it should be appended to the rest of the packages.

In this stage the YUM and/or APT repos should be (re)generated. I am putting the "(re)" into parenthesis because there are two possible subcases here:

    • B.1 the release should be appended to an already existed folder, where a YUM repo pre-exists.
    • B.2 the release should be moved to a new folder
      In the case of B.1: the YUM/APT repos should be regenereted, replacing the old ones.
      In the case of B.2, the YUM/APT repos provided by the SW provider should be used "as is".

One more action that has to be made by the Repository, is to change the "baseurl" value withn the given (by the SW provider) .repo files. NOTE: In case "we" want the rpms/deb to be digital signed, the repodata/Packages.gz should be recreated (overwriting the ones that SW provider provided).

  • Q1. I was wondering, are there any other use cases, that i can't figure-out right now?
  • Q2. Could it be wise approach, to include one more section in the release.xml file, thus the SW provider to be able to indicate
    • a. the "type" of the YUM/APT related workflow that he wants to follow (Delta, Semi-Delta, Typical etc.)
    • b. pointing, also, the directories within the release structure, under those the YUM/APT repositories should be (re)build
  • Q3. Could it be a more wise approach, the SW provider to be forced to give us the "location" on where the YUM and/or APT repositories he/she wants to build
     once every major release? (NOTE: in this way, he/she will not be able to change the schema, until the submission of the next major release)


--Kkoum 17:14, 28 September 2010 (UTC)