-
-
Notifications
You must be signed in to change notification settings - Fork 9.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
openssl.pod: Move detailed text on options to new specific pages like verification.pod #13315
Conversation
The OpenSSL page has all the common options. Moving just this one set of options seems like it's a partial job; if this is necessary they should all be moved. I don't understand the "seems unbalanced" comment. This PR makes things unbalanced. :) As a second issue, putting command line information into man7 is just plain bizarre. Perhaps splitting openssl.pod into man1/openssl-options.pod and moving all the option sections should be done. |
It may be unbalanced in the way you state here, but I found the original state unbalanced in a different way:
Your wording 'plain bizarre' is inappropriate. Also note that, as I wrote above to the first review comment, most of this text basically pertains to both the CLI and lib level, though the latter is not prominent and should be mentioned more explicitly.
I'd prefer to move each class of options to a separate file. |
That's true.
Right, I confused the day with the year - the commit is of Sat Oct 12 17:45:56 2019
Fine now :) I just found to my surprise that much of the CLI-vs-lib documentation redundancy is still there, at least regarding the verification flags, namely in |
Oops, @richsalz by mistake I put my responses to your last comment as an edit to your comment rather than quoting it in a new comment - sorry for that. |
a804273
to
5ae723a
Compare
@t8m and @richsalz I meanwhile I see/agree that most of the extracted contents is still very CLI-oriented. @richsalz, I agree that something similar {c,s}ould be done also for other classes of generic options, |
Glad you agree, but @DDvO it's not fair to do a part-way job and hope that the rest of the work will get done by someone else :) |
It's pretty typical that the one who brings up an issue is the first candidate for solving it, which in this case is you ;-) Actually there have been (and will be) loads of issues in OpenSSL (and elsewhere) where someone does an improvement while (for various reasons) does not at the same time fix further related issues. In this case, I do not strongly feel the need for the extra changes you requested, and (as mentioned) I currently have extremely limited time, so I do what I can and need to focus on my core topic, which is certificates. If neither you nor anybody else does further improvements in the direction indicated we can open an issue such that the need for further such cleanup is not forgotten. |
A couple of months ago, when some of us in the FIPS project were asking to just finish 3.0 now, to avoid slipping the schedule yet again, @mattcaswell explained that the 3.0 release is about more than just FIPS, and that OpenSSL believes it is important to have a coherent and comprehensive release. At this point, doing something part-way goes against that thread. It is annoying to see various "part of the way there" PR's, like this one, hoping that someone else will finish off the complete task. Actually it's more than annoying. Sure, as volunteers I understand how time is limited, and not everything is within every volunteer's level of expertise. But this particular PR isn't fixing protocol bugs, it's moving documentation around. A similar example is the "new" deprecation stuff which now has two ways of deprecating functions in header files because the original PR author wanted others to finish the job. I am sure there are other examples. At this point, I think the project should
I really think the projec |
@richsalz, for good reason I did not indicate that this PR is targeting 3.0 - it is not really urgent. |
5ae723a
to
709a310
Compare
After resolving merge conflicts, Travis timeout out (unrelated to the doc changes done here) on one build, |
I was wrong. I missed the milestone; I was looking only at the project field. (I still think many PR's are going to be part of 3.0 that aren't marked as such) Since there is a post-3.0 milestone, I think this should get marked with that. |
I am not in the position to decide on whether this PR should go into 3.0 or not. |
@t8m, thanks for the review you did a couple of days back. |
I am undecided on whether this is good change as whole or not. On one hand I agree that the openssl page is too long now and this would help making it shorter. On the other hand @richsalz has some merit in his arguments as well. |
How about the following suggestion: I mark this PR as WIP and hand it over to my new working student later this week, |
Yep, that could be a good way forward. |
709a310
to
1559deb
Compare
While I understand the desire to split things up file wise, I can see the risk for confusion when just reading the apropos output, for the very single reason that there is no command called This kind of restructuring needs to mature substantially... |
I'm also not too happy with this file name/location. Then I tried
So should I better use |
f4f0a5c
to
654b84d
Compare
ed06f1d
to
4a4a320
Compare
@seardes and me have meanwhile finished moving also other bulky (likely distracting) detail on So I've removed the |
@seardes, could you please rebase this to fix merge conflict that meanwhile came up. |
… and Format Options Move detailed doc to specific new files in doc/man1/openssl-*-options.pod
d308fe1
to
14adc65
Compare
@seardes, unfortunately your resolution of non-trivial merge conflicts went wrong. I've fixed this. |
As mentioned, meanwhile we have finished extending this PR. |
This pull request is ready to merge |
…special Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from #13315)
…on-options.pod Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> (Merged from #13315)
… and Format Options Move detailed doc to specific new files in doc/man1/openssl-*-options.pod Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: David von Oheimb <david.von.oheimb@siemens.com> (Merged from #13315)
|
||
=head1 NAME | ||
|
||
openssl-namefmt-options - DN display options |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Name display options" or "Distinguished name display options"
Also, I'm wondering if these shouldn't be exactly that throughout the manuals, "name display options". That would avoid having them mixed up with the other format options
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That includes the file name of this pod.
@@ -41,7 +41,7 @@ Print out a usage message. | |||
=item B<-inform> B<DER>|B<PEM> | |||
|
|||
The input format; the default is B<PEM>. | |||
See L<openssl(1)/Format Options> for details. | |||
See L<openssl-format-options(1)/Format Options> for details. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see the need to include the section. L<openssl-format-options(1)>
should suffice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This applies to every such link you changed 😉
Argh, I didn't notice this was closed... sorry |
While doing #13312 I noticed again that
details on certificate verification, including a rather long list of options, are part of the top-level
openssl
app documentation(and that
doc/man1/openssl-verify.pod.in
contains a very vague reference toopenssl.pod
).I felt that this is pretty imbalanced and moved those contents to a new .pod file, adapting the various references to it.