add version and git commit at compile time#244
add version and git commit at compile time#244jessfraz wants to merge 1 commit intoopencontainers:masterfrom
Conversation
|
this is part one in a series to get debs and rpms build 😇 |
|
This will likely fix #203.
|
|
Ah nice I will make this get the latest tag instead :) |
|
@LK4D4 looking at your comment from the issue linked i am going to propose the following:
then we will never need a version file again, and we can do this all in the greatest language ever, bash |
Makefile
Outdated
There was a problem hiding this comment.
You can get unfailable removal with rm -f runc. No need for the true fallback.
There was a problem hiding this comment.
I think the intention of the author is that " if the file runc is non-existed, it shouldn't fail".
if so, I prefer to
test ! -e runc || rm runcThere was a problem hiding this comment.
On Mon, Sep 07, 2015 at 07:56:45PM -0700, Lai Jiangshan wrote:
- rm runc
- rm runc || true
I think the intention of the author is that " if the file runc is
non-existed, it shouldn't fail".
rm(1) has:
-f, --force
ignore nonexistent files and arguments, never prompt
so there's no need for anything fancier than ‘rm -f runc’.
There was a problem hiding this comment.
i will update this tomorrow, you all can chill ;)
On Mon, Sep 7, 2015 at 8:24 PM, W. Trevor King notifications@github.com
wrote:
In Makefile
#244 (comment):@@ -26,7 +35,7 @@ install:
cp runc /usr/local/bin/runcclean:
- rm runc
- rm runc || true
On Mon, Sep 07, 2015 at 07:56:45PM -0700, Lai Jiangshan wrote: > - rm runc
- rm runc || true I think the intention of the author is that " if the
file runc is non-existed, it shouldn't fail".
rm(1) has:
… <#14faafbb7d161b07_>
-f, --force ignore nonexistent files and arguments, never prompt so
there's no need for anything fancier than ‘rm -f runc’.—
Reply to this email directly or view it on GitHub
https://github.com/opencontainers/runc/pull/244/files#r38888021.
|
@jfrazelle then how do we build without |
|
@tianon wdyt about hitting github.com instead then? |
Signed-off-by: Jessica Frazelle <acidburn@docker.com>
f3a193e to
901ca27
Compare
|
That'd be alright (not stellar but workable), but how do we know which
version on GitHub corresponds to the source we have locally on disk from a
source tarball?
|
|
ugh ya thats true, idk... maybe not having a VERSION file is not the best way I just know in #203 that was the suggestion :/ |
|
Alternatively, we could publish our own source tarballs with a generated
VERSION file in them, but that's even more work at release time than it's
worth IMO.
|
|
im so confused... what should we do haha |
|
@tianon why u gotta be so confusing? ;) So what's the plan here? |
|
Ok, let me be a bit more verbose then. 😄 I see a few options here.
This PR most closely aligns with 1 as-is, which is fine, but will definitely need some way for distros to specify the version number since they won't build with I'd put my personal vote on 2 (because it's the most balanced option), but I won't be responsible for maintaining the file so IMO my vote doesn't carry a lot of weight in this case. 😄 |
|
@jfrazelle you might want to look at my alternative in #404.. pulling the version from opencontainers/specs/version.go this might be what @tianon was talking about? Cheers. |
|
On Tue, Nov 17, 2015 at 10:13:21AM -0800, Mike Brown wrote:
Binding the runC version to the spec version seems like it would make
But like @tianon, I'm not going to be maintaining the releases, so my |
|
Two versions, one for the oci container code/spec and one for the runc binary? Which check goes in the config.json the one for the spec or the one for the runc binary? Hmm.... |
|
On Tue, Nov 17, 2015 at 11:09:56AM -0800, Mike Brown wrote:
The one for the spec goes in config.json. For example, if runC |
|
Fair enough... |
|
+1 on having decoupled versions. Pretty much like how docker handles the client/versioning API |
fix #203