-----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. kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+rtxkACgkQDC186MBRfro72wCfdfCRC4ck7lU+WWEtRqDr/NlY aoIAnRaTEieT/lFGr4abOUCb7ioFtY8o =Qr65 -----END PGP SIGNATURE-----
