On Thu, May 10, 2012 at 3:39 PM, David Sommerseth <openvpn.l...@topphemmelig.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/05/12 14:33, Alon Bar-Lev wrote: >> On Thu, May 10, 2012 at 11:47 AM, Samuli Seppänen >> <sam...@openvpn.net> wrote: >>> >>>> On Tue, May 8, 2012 at 11:28 AM, Samuli Seppänen >>>> <sam...@openvpn.net> wrote: >>>>>> Hello David, >>>>>> >>>>>> On Mon, May 7, 2012 at 10:33 AM, David Sommerseth >>>>>> <openvpn.l...@topphemmelig.net> wrote: >>>>>> >>>>>> <snip> >>>>>> >>>>>>> The reason I don't see the benefit of splitting out the >>>>>>> plug-ins as much is that they all depend on OpenVPN. You >>>>>>> can not make much use of these plug-ins without having >>>>>>> OpenVPN. But with Windows TAP driver and easy-rsa, they >>>>>>> can be completely used independently. >>>>>>> >>>>>>> Another point is that the plug-ins we have in the source >>>>>>> tree, is officially supported plug-ins. And especially >>>>>>> auth-pam and down-root are plug-ins which are very useful >>>>>>> and we should encourage packagers to always package >>>>>>> those. >>>>>>> >>>>>>> Then the example/ and defer/ plug-ins, which are >>>>>>> examples. Maybe it would rather make sense to merge them >>>>>>> somehow? >>>>>> There are a lot of plugins out there, think about chrome >>>>>> extension or firefox extension, but also network manager >>>>>> plugins or similar, they are all depend on the core >>>>>> product, but extend its functionality, and have their own >>>>>> repositories. >>>>>> >>>>>> Plugins should be installed as separate package, aka rpm. >>>>>> >>>>>> So if administrator wants openvpn he does: # yum install >>>>>> openvpn >>>>>> >>>>>> Now, if administrator wants auth-pam, he should do: # yum >>>>>> install openvpn-plugin-auth-pam >>>>>> >>>>>> As there is no sense in keeping the auth-pam plugin in >>>>>> system if it is unused nor to have pam dependency of the >>>>>> openvpn core package. >>>>>> >>>>>> I would not encourage packages to always have them, it is >>>>>> also not the correct approach for plugins. Plugins should >>>>>> be optional in nature. >>>>>> >>>>>> All the above does not imply separate repository as in both >>>>>> cases we can either provide one .spec file that generate >>>>>> both rpms or two separate spec files. >>>>>> >>>>>> The real question is how do we provide proper build for >>>>>> this components. Currently it has poor-man-build, which I >>>>>> fixed to meet some level of quality, instead of >>>>>> ./configure&&make install, packager should go and figure >>>>>> own what else needs to be built in tree. >>>>>> >>>>>> So either these are officially supported and should be >>>>>> build properly using main build system, example: --- $ >>>>>> ./configure --enable-plugin-auth-pam PAM_CFLAGS=... >>>>>> PAM_LIBS=... --- >>>>>> >>>>>> Or have plugins as separate components with its own release >>>>>> cycle and should have their proper own build system and >>>>>> release cycle. >>>>>> >>>>>> I think that if we have proper interface >>>>>> (openvpn-plugin.h), there is no sense in providing the >>>>>> plugins within the tree, as it has its own release cycle. >>>>>> >>>>>> I also would like to discuss the "official" argument.... A >>>>>> project can have several repositories all at equal >>>>>> "official" level, why on earth people think that having >>>>>> more than one repository around damage their "official" >>>>>> state? "officially supported plug-ins", can be official in >>>>>> the openvpn repository and can be official in their own >>>>>> repository, there is absolutely no difference between the >>>>>> two approaches in this regards. >>>>>> >>>>>> However, splitting the repositories, allow helping distro >>>>>> packaging in determine what needed to be packaged and >>>>>> provided to users, it also allow separate release cycle >>>>>> (new openvpn release does not force new plugin release), >>>>>> and can even help in maintenance as a plugin can have its >>>>>> own maintainer (commit access). >>>>>> >>>>>> If also has more advantage as now in github we can >>>>>> encourage people to host and maintain their plugin within >>>>>> the OpenVPN organization, attracting more skills. So bottom >>>>>> line: >>>>>> >>>>>> 1. Either we add the plugins to core build system, with its >>>>>> disadvantages. >>>>>> >>>>>> 2. Split plugins into their own repository, release cycle, >>>>>> packaging. >>>>>> >>>>>> I am for (2), as I don't afraid of the "official" argument >>>>>> nor do I afraid to commit to more than one repository, and >>>>>> the modular nature of the plugin interface allows optional >>>>>> components to be installed separately along with their own >>>>>> dependencies. >>>>>> >>>>>> Alon >>>>> I think there's some very good argumentation here. In my >>>>> view, separating plugins into their own repositories would >>>>> have some important advantages; excuse me for repeating some >>>>> of Alon's arguments here: >>>>> >>>>> 1) Delegating maintenance tasks easily to (new) developers: >>>>> this is now trivial with GitHub 2) Avoid having to make an >>>>> OpenVPN release due to an important fix in a plugin used by >>>>> few. This also helps distro packagers, provided they didn't >>>>> bundle the plugins in their core "openvpn" package >>>>> >>>>> Afaik none of the official plugins are needed to create the >>>>> official Windows installers, so that platform is entirely >>>>> unaffected. On *NIX side we only release source code. If we >>>>> don't want to force people to fetch official plugin code >>>>> using Git, providing tarballs would be trivial. >>>>> >>>>> I tend to agree that packagers should take care of packaging >>>>> the plugins as they see fit and making sure they're >>>>> compatible with their version of OpenVPN. For example, on >>>>> Debian/Ubuntu the OpenVPN package includes "down-root" and >>>>> "pam" plugins by default. However, I've never used those, and >>>>> I know many others who don't either. Having the plugins in >>>>> separate repositories would steer packagers to the (in my >>>>> opinion) right direction of packaging optional functionality >>>>> as optional packages. They already do this for some of the >>>>> off-tree plugins: >>>>> >>>>> <https://community.openvpn.net/openvpn/wiki/RelatedProjects> >>>>> >>>>> I believe the primary reason why the "pam" and "down-root" >>>>> plugins are in OpenVPN repository is that they seem to come >>>>> from James, who has a use-case for them. Personally, I would >>>>> rather see the plugins in their own repositories, even if >>>>> only to see if it fosters collaboration. >>>>> >>>>> I guess that was my 5 cents :). >>>>> >>>>> -- Samuli Seppänen Community Manager OpenVPN Technologies, >>>>> Inc >>>>> >>>>> irc freenode net: mattock >>>>> >>>> Hello, >>>> >>>> In order to break the fear I just went ahead and did this... >>>> maybe this will relax some of the concerns... >>>> >>>> A plugin in own repository, own build system, own rpm packaging >>>> of auth-pam[1] and down-root[2], even ebuilds[3][4]! >>>> >>>> Now we have the following packages for rpm based system: >>>> >>>> - openvpn - openvpn-devel (openvpn-plugin.h) - >>>> openvpn-plugin-auth-pam (introduces the pam dependency) - >>>> openvpn-plugin-down-root >>>> >>>> I've prepared a openvpn branch[5] to support this migration, I >>>> think that the best example is to see how the rpm spec file >>>> was simplified[6], no none standard statement, simple configure >>>> and make process, less dependencies for core package. >>>> >>>> I think that in the Gentoo ebuild[7] we can see more verbose >>>> example, especially the following statement that is about to be >>>> removed: --- if ! use minimal ; then cd src/plugins for i in *; >>>> do [[ ${i} == "README" || ${i} == "examples" || ${i} == "defer" >>>> ]] && continue [[ ${i} == "auth-pam" ]] && ! use pam && >>>> continue einfo "Building ${i} plugin" emake -C "${i}" >>>> CC="$(tc-getCC)" CFLAGS="${CFLAGS}" LDFLAGS="${LDFLAGS}" done >>>> cd .. --- >>>> >>>> I truly hope you see the advantage in building and packaging >>>> each independent component by its own, the simplicity it >>>> introduces in term of code maintenance and system >>>> administration. Again, there is no impact of the official level >>>> of the components. >>>> >>>> Best Regards, Alon Bar-Lev. >>>> >>>> [1] https://github.com/OpenVPN/openvpn-plugin-auth-pam [2] >>>> https://github.com/OpenVPN/openvpn-plugin-down-root [3] >>>> https://github.com/alonbl/alon-barlev-overlay/blob/master/net-misc/openvpn-plugin-auth-pam/openvpn-plugin-auth-pam-9999.ebuild >>>> >>>> > [4] > https://github.com/alonbl/alon-barlev-overlay/blob/master/net-misc/openvpn-plugin-down-root/openvpn-plugin-down-root-9999.ebuild >>>> [5] https://github.com/alonbl/openvpn/compare/master...plugins >>>> [6] >>>> https://github.com/alonbl/openvpn/commit/0a9a1e1f234dcc81d4ed9ece5f894cfe5ec02d01#diff-0 >>>> >>>> > [7[ > https://github.com/alonbl/alon-barlev-overlay/blob/master/net-misc/openvpn/openvpn-9999.ebuild >>> >>> Hi Alon, >>> >>> Ok, so this is kind of a preview, which I think is fine. We >>> should definitely look at these plugin repositories and see how >>> it all fits together. I only got one minor nitpick... I think >>> your own ("alonbl") GitHub repos would have been a more >>> appropriate place for these plugin repositories for now, as >>> they're not "officially" approved yet. >>> >>> -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc >>> >>> irc freenode net: mattock >>> >> >> Well, among others, the mission was to create a community around >> openvpn with extras, so that people will find VPN resources at one >> place... > > Agreed. > >> What official or not, who is the maintainer of what, what level of >> release and what the level of support should be documented in the >> wiki or other place. > > We have not reached any agreement on splitting out the plug-ins or > not. So putting them in an area which can be understood as a official > repository is not okay. > >> If you want, I can remove these, no problem, but I needed to raise >> these arguments. > > Please put them in your own repository, and what we put under the > OpenVPN organisation part will be what we have as official repositories. >
I will. But how can you agree the above... :) Anyway, I would like to get your updated response on this split... Alon.
