path: root/README.SRC_URI
diff options
authorYong-iL Joh <yong-il.joh@windriver.com>2016-09-23 18:05:34 +0900
committerYong-iL Joh <yong-il.joh@windriver.com>2016-09-23 18:05:34 +0900
commitdf04ca7fb3e20aa247e7c2f44a74ff80b63e3b96 (patch)
tree0fde3377f5f6be7ae4b2be8c69196400bf16c782 /README.SRC_URI
parent6d0c543860532f95fca5dbb5e6e8ef7976f95b55 (diff)
parentfa4a1314e536450ad1ccfe33499b5601ac4e68c1 (diff)
Merge branch '11'
Diffstat (limited to 'README.SRC_URI')
1 files changed, 50 insertions, 0 deletions
new file mode 100644
index 0000000..4f87a96
--- /dev/null
@@ -0,0 +1,50 @@
+talk about using SRCREV instead of branch or tag at SRC_URI
+Sent: Tuesday, April 05, 2016 11:33 PM
+To: James Thomas
+Cc: genivi-meta-ivi@lists.genivi.org
+Subject: Re: [meta-ivi] Building with local source mirror
+On Tue, Mar 29, 2016 at 10:51 PM, James Thomas <james.thomas@codethink.co.uk> wrote:
+> One thing I noticed is that simply providing the SRCREV works as long
+> as that sha exists within master, if it doesn't then you have a build
+> error, so being able to use tags is useful.
+> I think using git://...;tag=foo is not sufficient, because tags *can*
+> change (i.e there's no guarantee that the tag you're using is going to
+> be the same as the one you used yesterday).
+> What would be nice is if you could go tag=foo, and have it verified
+> against SRCREV (in my testing this resulted in a build error *when*
+> the tag and sha matched)
+> However, something like
+> SRC_URI = "git://mygitrepo/foo.git;nobranch=1;branch=v0.2"
+> SRCREV = "7654321"
+> does enforce that check (v0.2 is actually a tag in this case), which
+> seems to be pretty useful (the recipe provides something human
+> readable, and something a machine can understand, and will always
+> check they match)
+I completely understand the reasoning behind this. The point I'm trying to
+ make is that the automotive industry has a strong need for reproducible
+ offline builds and any kind of mandatory online checks break this requirement.
+ And like Federico said, using SRCREV is also the Yocto project practice.
+If we want meta-ivi to be widely used in the industry I believe it should
+ support it's needs. In my opinion the same should go for the whole GENIVI
+ stack to work nicely, which in particular means tags of the projects should
+ not change. But the easiest solution would be for meta-ivi to not use tags.
+ That way it supports offline builds and it is also possible to track bugfixes
+ in the projects instead of pinning to the tag and then getting the bugfixes
+ in patch by patch until next release.
+How do the others on this list feel about this proposal?
+Igor Socec
+Software Engineer