Hi Nilesh, Am 6. Juli 2021 18:25:51 MESZ schrieb Nilesh Patra <[email protected]>: >Hi Peymaneh, > >On 7/6/21 9:28 PM, Peymaneh Nejad wrote: >> This package[1] provides a builddependency for caddy: >> github.com/smallstep/cli/crypto/x509utils >> >> Initially I wanted to package the whole project, including its binary >> step-cli that seems to be a very useful tool to me. I revisited my plans and >> would propose to only package the library that is needed for caddy. As of >> now, it excludes any sourcecode not needed for providing >> github.com/smallstep/cli/crypto/x509utils to keep the dependences simple >> >> my reasoning is that the binary pulls a lot of dependencies that are forks >> by the smallstep developers of other packages to suite the developers needs >> (See my last RFS on this ML). A complete overview is here[1]. >> >> Nilesh already wrote sometimes that they'd rather not upload forks if >> avoidable. An alternative would be to apply all the patches needed for >> building step-cli. . I skimmed through the source code and to me it seems >> that patching the original packages could break the intended functionality >> of several of the packages like zmap/zcrypto. I also fear that my novice >> programming skills together with my tight schedule are not the best >> situation for mangling around with code that is intended for verification >> and linting of TLS certificates. > >IMO, if you can, you really should package this binary. I think the target is >not to get everything in somehow, but to get all packages in excellent >condition that might leave minimal scope for improvement. >The only problem I see here is that if at some point in time, we need >smallstep-cli, then we'll have to loop via NEW queue again, which I prefer >avoiding. >However, if you think that this is redundant, and we can just go ahead with >the binary, fair enough.
Acknowledged. I didn't consider that a later package split might be an issue. To avoid double looping via NEW queue we could wait with an upload, and once I am done with the other dependencies and caddy packaging, I would revisit smallstep/cli and see if there is maybe time to do a binary package. What do you think? Anyhow, in case I can't make it within GSoC timeline, I would definitely like to improve it at some later point. Figuring my way through these dependencies sounds like a good learning experience also >> mejo also approves of going for the first option. >Alright. > >> Please let me know what you think. >> If you approve, there would be two other questions: >> * right now, the package description explains that the package only provides >> this one library, do you think it would be appropriate to add a README file >> or something explaining this explicitly? > >Why not simply expand the extended description? > >> * for a source-only package golang-github-thomasrooney-gexpect >> (New queue) would not be needed anymore, I would then cancel the upload? > >Nah, let's just keep it around, some other package might need this. It is >pretty low maintainance, so should be fine. Perfect. Peymaneh
