Hi David, other, It seems that my "I'm using my phone, sorry for top posting" went far beyond that because I also forgot to add the list as a recipient.
So, here is my message (minus the top-posting) sent to David only (sorry David) On Tue, Jul 25, 2017 at 9:21 PM, David Woodhouse <dw...@infradead.org> wrote: > > On Tue, 2017-07-25 at 19:53 +0300, Samuli Seppänen wrote: > > > > I released the new Windows installer but without this patch. That said, > > the patch/PR you linked to makes sense. Does the patch have an active > > maintainer? > > That would be me, I suppose. Until/unless the upstream maintainer > applies the patch, I or someone else will continue to maintain the > patch in the Fedora package at least. > > > If yes, then I propose is that we > > > > - Fork OpenSC/pkcs11-helper to OpenVPN/pkcs11-helper > > - Apply the patch to our fork > > - Produce and publish our own pkcs11-helper tarballs > > - Point openvpn-build to our tarballs > > - Periodically rebase our fork with upstream > > > > Thoughts? > > > Hi, > > Sorry for the top posting, I'm writing that from my phone. > > To add to the NAK, such a move would make integration to various embedded > distribution more difficult, as maintainers may have to deal with 2 versions > of the > same lib (with possibly different behavior needed by different binaries). > > Do I would advise against such a solution. > > Best regards, > > -- Emmanuel Deloget To which David replied (hope you don't mind if I quote you): > There is no API/ABI change. One accepts cert identifier strings confirming > to RFC7512, the other (without the patch) doesn't. > > So aside from the RFC-compliance they are interchangeable. (I think I'm already using this patch, so thanks you David for your work). A single patch would not a a problem for distro maintainers, but subsequent/future changes in the forked repository might introduce other, less compatible changes in the library, leading to two versions of the same library, with maybe the same ABI and the same name -- and that worries me a bit (not that much, but I also maintain a fork of lede for my own purpose, and I'm not sure I'd like to deal with such complexity :)). Aviding that would require a library name change and I'm not sure it's a good thing at all. And you also have to take into account weird people like me who also add their own changes into various libraries or binaries to suit their needs (the whole "hey, it's free software, I can change it" thing). Pointing them to a fork is not going to work well IMHO. It would be better if the maintainer finally decide to either implement the required change or merge your patch to the library. Best regards, -- Emmanuel Deloget ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
