Project

General

Profile

Issue #789

Consider including repo manifest -r output with distributed images

Added by Riku Saikkonen over 6 years ago. Updated over 5 years ago.

Status:
Rejected
Priority:
Normal
Category:
-
Target version:
Start date:
01/05/2014
Due date:
% Done:

0%

Estimated time:
Resolution:
invalid
Device:

Description

The Replicant build directories contain a git_versions.txt file containing git commit IDs from subprojects. (For example, http://ftp.osuosl.org/pub/replicant/sdk/replicant-4.0/0001/infos/git_versions.txt .) However, there doesn't seem to be a way to use this file automatically, for example to rebuild an image using the same versions of software than in the distributed image. It appears that the build instructions in e.g. SDKBuild produce a current version of most software in the image, and not the versions that Replicant distributes. (Because the Replicant manifest default.xml does not contain exact revision information for most of the subprojects.)

However, the repo tool appears to be able to generate a manifest containing the commit IDs: repo manifest -r -o mymanifest.xml

I assume that if this generated manifest was included in, e.g., the replicant/manifest repository as, say, sdk_4.0_0001.xml, then one could view the sources and/or rebuild this exact version of the SDK with: repo init -u git://gitorious.org/replicant/manifest.git -m sdk_4.0_0001.xml
(probably also with repo sync -m sdk_4.0_0001.xml, from what I understand of "repo help sync")

There is also a "smart tag" option in repo (repo sync -t), which seems to be designed for fetching a particular version (a "known good build" is the example the help uses), but it seems to require setting up something called a "manifest server" on the network that would respond to these kinds of queries. Storing manifests containing commit IDs in files seems to be a much simpler approach.

Another approach would of course be for Replicant to distribute the source code of each image along with the binaries, but the files are rather huge. (repo init + repo sync of replicant-4.0 takes about 21 gigabytes on disk right now. Although I guess you could distribute only the then-current version and not the revision history: a .tar.gz of everything except the .repo subdirectory is "only" 2.5 gigabytes, and I assume that it (or a shallow clone, repo init --depth=1) would be enough for rebuilding.)

(Disclaimer: I did not have time to test that the repo init/sync stuff actually works, but the generated manifest looked correct. Sorry for not testing properly, but I thought it would be better to write this bug report quickly, as I heard you may be producing new images in the near future, and it is difficult to create this versioned manifest afterwards if you modify or re-sync the build directory...)

History

#1

Updated by Paul Kocialkowski over 6 years ago

  • Status changed from New to Rejected
  • Resolution set to invalid

Please do not use the bug tracker for this! How is that possible a bug with our software?
Could you please copy that to a forum thread? Thanks

I'll be happy to respond then :)

#2

Updated by Riku Saikkonen over 6 years ago

Paul Kocialkowski wrote:

Please do not use the bug tracker for this! How is that possible a bug with our software?
Could you please copy that to a forum thread? Thanks

Ok, I did that now. Sorry for reporting a useless "bug" - some other projects use bug trackers to also keep track of feature requests, and I forgot to check whether that's the case with Replicant...

#3

Updated by Paul Kocialkowski over 5 years ago

  • Target version changed from 21 to Any version

Also available in: Atom PDF