[
https://issues.apache.org/jira/browse/HADOOP-12651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15108777#comment-15108777
]
Allen Wittenauer edited comment on HADOOP-12651 at 1/20/16 3:57 PM:
--------------------------------------------------------------------
Thanks for the review and feedback!
bq. Since this is targeting trunk, it probably isn't necessary to redirect the
old scripts to invoke the new ones, even to remain compatible with existing
tooling/automation.
Redirecting would be extremely tricky anyway: smart-apply-patch, for example,
uses wholly incompatible command line options. So by not doing the redirection,
we'll force folks to recognize that the world has changed, even the 90% of
folks that don't read common-dev.
bq. A README under dev-support would be helpful, though.
That's a good idea, especially given the above. Will add.
bq. To upgrade to new versions of Yetus, one bumps the version in yetus-wrapper?
Yup. I've been debating adding the ability to fetch from the source tree. This
week's thought process has mainly been: no, bad idea, because if the source
tree changes form (highly likely) then this would need to get touched again.
Plus there's already the ability to point to a built version somewhere else, so
if someone really wants to use master, they can always go that route.
bq. Downloading YETUS_KEYS and the .asc could probably be put within the check
for $GPGBIN.
Good idea.
bq. If the tarball exists but the result of extracting it doesn't, should this
attempt to re-download the tarball (and .asc), assuming the last one was
corrupt? The -f check that avoids the download seems more likely to wedge in
this case than avoid skippable work.
Hmm. I see it the potential issue. Let me think about how to fix this. I
definitely need to add more error checking there as well as rm the tarball if
extract fails.
bq. Is the "z" option nonstandard for tar?
Yes, it's nonstandard. It's a GNU extension.
was (Author: aw):
Thanks for the review and feedback!
bq. Since this is targeting trunk, it probably isn't necessary to redirect the
old scripts to invoke the new ones, even to remain compatible with existing
tooling/automation.
Redirecting would be extremely tricky anyway: smart-apply-patch, for example,
uses wholly incompatible command line options. So by not doing the redirection,
we'll force folks to recognize that the world has changed, even the 90% of
folks that don't read common-dev.
bq. A README under dev-support would be helpful, though.
That's a good idea, especially given the above. Will add.
bq. To upgrade to new versions of Yetus, one bumps the version in yetus-wrapper?
Yup. I've been debating adding the ability to fetch from the source tree. This
week's thought process has mainly been: no, bad idea, because if the source
tree changes form (highly likely) then this would need to get touched again.
Plus there's already the ability to point to a built version somewhere else, so
if someone really wants to use master, they can always go that route.
bq. Downloading YETUS_KEYS and the .asc could probably be put within the check
for $GPGBIN.
Good idea.
bq. If the tarball exists but the result of extracting it doesn't, should this
attempt to re-download the tarball (and .asc), assuming the last one was
corrupt? The -f check that avoids the download seems more likely to wedge in
this case than avoid skippable work.
Hmm. I see it the potential issue. Let me think about how to fix this. I
definitely need to add more error checking there as well as rm the tarball if
extract fails.
bq. Is the "z" option nonstandard for tar?
Nope. It's a GNU extension.
> Replace dev-support with wrappers to Yetus
> ------------------------------------------
>
> Key: HADOOP-12651
> URL: https://issues.apache.org/jira/browse/HADOOP-12651
> Project: Hadoop Common
> Issue Type: New Feature
> Components: scripts
> Affects Versions: 3.0.0
> Reporter: Allen Wittenauer
> Assignee: Allen Wittenauer
> Attachments: HADOOP-12651.00.patch, HADOOP-12651.01.patch,
> HADOOP-12651.02.patch
>
>
> Now that Yetus has had a release, we should rip out the components that make
> it up from dev-support and replace them with wrappers. The wrappers should:
> * default to a sane version
> * allow for version overrides via an env var
> * download into patchprocess
> * execute with the given parameters
> Marking this as an incompatible change, since we should also remove the
> filename extensions and move these into a bin directory for better
> maintenance towards the future.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
