install: Extract autoconf-archive install to separate script #876
Conversation
| # | ||
|
|
||
| # autoconf-archive url | ||
| autoconf_archive_url="http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4" |
There was a problem hiding this comment.
I recently added autoconf_archive to Clear Linux, what do you think to chanage that url with something like this
https://ftp.gnu.org/gnu/autoconf-archive/autoconf-archive-2017.03.21.tar.xz
There was a problem hiding this comment.
I think I like the versioned link better than the gitweb one, yes.
What do you think - we can just pull the tar file and extract just the files we need into the m4 directory with a single piped tar command maybe?
There was a problem hiding this comment.
I think this decision effectively summarises to:
- do we want to remain on the development tip of autoconf-archive (gitweb)? or,
- do we want stability at the expense of using old code (ftp)?
I'd leaning slightly towards the former since otherwise we have something else to maintain (if we go with the latter we should add the package version to versions.txt). If the GNU tip does break, we can raise a PR to revert to the last good commit. That said, I can't imagine that the two m4 files we're using are going to change significantly enough to warrant tracking the top of development. However, by remaining current, we'll ensure RHEL/CentOS are more in line with the other distros (which presumably will update the autoconf-archive package as new versions are released upstream.
There was a problem hiding this comment.
Nice breakdown @jodh-intel With that info, I think I agree that longer term the development tip is safe enough (these are very low churn files)...
@jcvenegas , what say you?
There was a problem hiding this comment.
@grahamwhaley @jodh-intel , not problem here, I was curious to be a consistent with the versions.txt, it already includes a version for "autoconf_archive_version", and in case of that happen, we potentially could know about it and fix it quickly
|
Looks good looks very helpful ! I think it could be nice to have some documentation about it somewhere or add an option to configure.ac to do something like: |
|
@jcvenegas I mocked up some docs locally that lived as an indented paragraph in here: https://github.com/01org/cc-oci-runtime/blame/master/README.rst#L209 but, it feels odd, and I'm not sure that is the correct or best place. @jodh-intel any thoughts on this? |
|
@jcvenegas @devimc @jodh-intel For the autoconf addition... two things:
|
|
@grahamwhaley sure lets make the autoconf thing not a blocker, we can added it latter if needed |
|
Just to nudge this forwards, here is the doc snippet (in a temporary branch/commit) I tried out.
|
|
@gorozco1 @jodh-intel with #911 , is this PR now redundant - shall I shut it down? |
|
I think it is still useful for RHEL and CentOS which don't provide an |
|
Due to the problems we're experiencing with the http://savannah.gnu.org/ site (see #946), I think this script is definitely needed, but should download the whole archive and extract just the files we need. A mirror like |
|
@grahamwhaley I think this script is still needed for RHEL/CentOS |
|
Update: savannah is back so we have some thinking time now ;) |
|
This has been hanging here for some time - it is 'self documenting' in the Issue, and mostly we have moved on past this issue, but the script is still useful. Drop the DNM tag, and let's merge it. |
|
lgtm |
|
qa-failed |
|
@chavafg any information why tests failed ? |
|
Seems that PR needs a rebase, so it runs the |
|
@grahamwhaley could you rebase the PR ? |
Under some circumstances it is needed to 'hand install' the m4 scripts. This was done in the rhel install script, but sometimes it is really useful to be able to do that by hand, so extract the relevant commands into their own script (to allow hand running), and get the rhel script to invoke that new script at the appropriate time. Fixes: intel#875 Signed-off-by: Graham Whaley <[email protected]>
grahamwhaley
force-pushed
the
20170504_curl_auto_macros
branch
from
78560f5 to
82cfb1f
Compare
|
Rebase done and pushed. I am not set up to easily verify this patch at present, but a visual check shows the changes appear identical after the rebase. If somebody feels they are set up and would like to do a test run of the rhel installer, please do. |
|
qa-failed |
|
this is a qa-passed, but for some reason old logs didn't get cleared and they make this failed. Will look into the ci issue. |
|
qa-passed |
|
lgtm |
Under some circumstances it is needed to 'hand install' the m4
scripts. This was done in the rhel install script, but sometimes
it is really useful to be able to do that by hand, so extract the
relevant commands into their own script (to allow hand running),
and get the rhel script to invoke that new script at the appropriate
time.
Fixes: #875
Signed-off-by: Graham Whaley [email protected]