Alon Bar-Lev | 6 May 18:55 2012
Picon

[RFC] Split plugins into their own repositories

Hello,

Now, I also have the courage to ask one more question regarding build....

We currently have:
- auth-pam
- defer
- down-root
- examples

Distribution wise it will be best to allow admin to install plugins as
own package which requires openvpn, allowing select specific plugins,
while each has own release cycle and versioning.

I already made the openvpn-plugin.h available in /usr/include, so
there is no real reason to keep the plugins in openvpn tree, as they
can be complied using their own separate build system.

for example, if we take RHEL, we can install the following to use the
auth-pam plugin:

openvpn
openvpn-plugin-auth-pam

To build plugin we need openvpn-devel.

What do you say?

BTW: next will be probably to split out the contrib... :)

(Continue reading)

Adriaan de Jong | 7 May 09:23 2012

Re: [RFC] Split plugins into their own repositories

> -----Original Message-----
> From: Alon Bar-Lev [mailto:alon.barlev <at> gmail.com]
> Sent: zondag 6 mei 2012 18:55
> To: openvpn-devel <at> lists.sourceforge.net
> Subject: [Openvpn-devel] [RFC] Split plugins into their own
> repositories
> 
> Hello,
> 
> Now, I also have the courage to ask one more question regarding
> build....
> 
> We currently have:
> - auth-pam
> - defer
> - down-root
> - examples
> 
> Distribution wise it will be best to allow admin to install plugins as
> own package which requires openvpn, allowing select specific plugins,
> while each has own release cycle and versioning.
> 
> I already made the openvpn-plugin.h available in /usr/include, so there
> is no real reason to keep the plugins in openvpn tree, as they can be
> complied using their own separate build system.
> 
> for example, if we take RHEL, we can install the following to use the
> auth-pam plugin:
> 
> openvpn
(Continue reading)

Alon Bar-Lev | 7 May 09:33 2012
Picon

Re: [RFC] Split plugins into their own repositories

On Mon, May 7, 2012 at 10:23 AM, Adriaan de Jong <dejong <at> fox-it.com> wrote:
>> -----Original Message-----
>> From: Alon Bar-Lev [mailto:alon.barlev <at> gmail.com]
>> Sent: zondag 6 mei 2012 18:55
>> To: openvpn-devel <at> lists.sourceforge.net
>> Subject: [Openvpn-devel] [RFC] Split plugins into their own
>> repositories
>>
>> Hello,
>>
>> Now, I also have the courage to ask one more question regarding
>> build....
>>
>> We currently have:
>> - auth-pam
>> - defer
>> - down-root
>> - examples
>>
>> Distribution wise it will be best to allow admin to install plugins as
>> own package which requires openvpn, allowing select specific plugins,
>> while each has own release cycle and versioning.
>>
>> I already made the openvpn-plugin.h available in /usr/include, so there
>> is no real reason to keep the plugins in openvpn tree, as they can be
>> complied using their own separate build system.
>>
>> for example, if we take RHEL, we can install the following to use the
>> auth-pam plugin:
>>
(Continue reading)

David Sommerseth | 7 May 09:33 2012
Picon

Re: [RFC] Split plugins into their own repositories


On 06/05/12 18:55, Alon Bar-Lev wrote:
> Hello,
> 
> Now, I also have the courage to ask one more question regarding
> build....
> 
> We currently have: - auth-pam - defer - down-root - examples
> 
> Distribution wise it will be best to allow admin to install plugins
> as own package which requires openvpn, allowing select specific
> plugins, while each has own release cycle and versioning.
> 
> I already made the openvpn-plugin.h available in /usr/include, so 
> there is no real reason to keep the plugins in openvpn tree, as
> they can be complied using their own separate build system.
> 
> for example, if we take RHEL, we can install the following to use
> the auth-pam plugin:
> 
> openvpn openvpn-plugin-auth-pam
> 
> To build plugin we need openvpn-devel.
> 
> What do you say?

I am not quite sure I see the benefit of this.  Just let me first
explain why I find the current splits fine.

Splitting out windows build stuff made sense, as openvpn is buildable
(Continue reading)

Alon Bar-Lev | 7 May 10:04 2012
Picon

Re: [RFC] Split plugins into their own repositories

Hello David,

On Mon, May 7, 2012 at 10:33 AM, David Sommerseth
<openvpn.list <at> 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

(Continue reading)

Samuli Seppänen | 8 May 10:28 2012
Picon

Re: [RFC] Split plugins into their own repositories


> Hello David,
>
> On Mon, May 7, 2012 at 10:33 AM, David Sommerseth
> <openvpn.list <at> 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
>
(Continue reading)

Alon Bar-Lev | 10 May 00:04 2012
Picon

Re: [RFC] Split plugins into their own repositories

On Tue, May 8, 2012 at 11:28 AM, Samuli Seppänen <samuli <at> openvpn.net> wrote:
>
>> Hello David,
>>
>> On Mon, May 7, 2012 at 10:33 AM, David Sommerseth
>> <openvpn.list <at> 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
(Continue reading)

Samuli Seppänen | 10 May 10:47 2012
Picon

Re: [RFC] Split plugins into their own repositories


> On Tue, May 8, 2012 at 11:28 AM, Samuli Seppänen <samuli <at> openvpn.net> wrote:
>>> Hello David,
>>>
>>> On Mon, May 7, 2012 at 10:33 AM, David Sommerseth
>>> <openvpn.list <at> 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
(Continue reading)

Alon Bar-Lev | 10 May 14:33 2012
Picon

Re: [RFC] Split plugins into their own repositories

On Thu, May 10, 2012 at 11:47 AM, Samuli Seppänen <samuli <at> openvpn.net> wrote:
>
>> On Tue, May 8, 2012 at 11:28 AM, Samuli Seppänen <samuli <at> openvpn.net> wrote:
>>>> Hello David,
>>>>
>>>> On Mon, May 7, 2012 at 10:33 AM, David Sommerseth
>>>> <openvpn.list <at> 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:
(Continue reading)

David Sommerseth | 10 May 14:39 2012
Picon

Re: [RFC] Split plugins into their own repositories


On 10/05/12 14:33, Alon Bar-Lev wrote:
> On Thu, May 10, 2012 at 11:47 AM, Samuli Seppänen
> <samuli <at> openvpn.net> wrote:
>> 
>>> On Tue, May 8, 2012 at 11:28 AM, Samuli Seppänen
>>> <samuli <at> openvpn.net> wrote:
>>>>> Hello David,
>>>>> 
>>>>> On Mon, May 7, 2012 at 10:33 AM, David Sommerseth 
>>>>> <openvpn.list <at> 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
(Continue reading)

Alon Bar-Lev | 10 May 14:42 2012
Picon

Re: [RFC] Split plugins into their own repositories

On Thu, May 10, 2012 at 3:39 PM, David Sommerseth
<openvpn.list <at> 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
>> <samuli <at> openvpn.net> wrote:
>>>
>>>> On Tue, May 8, 2012 at 11:28 AM, Samuli Seppänen
>>>> <samuli <at> openvpn.net> wrote:
>>>>>> Hello David,
>>>>>>
>>>>>> On Mon, May 7, 2012 at 10:33 AM, David Sommerseth
>>>>>> <openvpn.list <at> 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.
>>>>>>>
(Continue reading)

Alon Bar-Lev | 10 May 15:48 2012
Picon

Re: [RFC] Split plugins into their own repositories

On Thu, May 10, 2012 at 3:42 PM, Alon Bar-Lev <alon.barlev <at> gmail.com> wrote:
> On Thu, May 10, 2012 at 3:39 PM, David Sommerseth
> <openvpn.list <at> 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
>>> <samuli <at> openvpn.net> wrote:
>>>>
>>>>> On Tue, May 8, 2012 at 11:28 AM, Samuli Seppänen
>>>>> <samuli <at> openvpn.net> wrote:
>>>>>>> Hello David,
>>>>>>>
>>>>>>> On Mon, May 7, 2012 at 10:33 AM, David Sommerseth
>>>>>>> <openvpn.list <at> 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.
(Continue reading)

Eric Crist | 12 May 23:22 2012
Picon

Re: [RFC] Split plugins into their own repositories

My two cents on this is as follows:

As a package maintainer, I think this is going to prove to be a lot of work.  It means there are more packages to
maintain, over the one I need to now.  HOWEVER, from the OpenVPN development process, I think it's best to
split things out, as Alon suggests, with one caveat.  Let's wait for 3.0.  That's already going to be a
massive change to our source tree and overall build process, and I think it would be the right time to push
that out.

Hope this helps.
-----
Eric F Crist

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Gert Doering | 13 May 11:01 2012
Picon

Re: [RFC] Split plugins into their own repositories

Hi,

On Sat, May 12, 2012 at 05:22:52PM -0400, Eric Crist wrote:
> My two cents on this is as follows:
> 
> As a package maintainer, I think this is going to prove to be a lot of 
> work.  It means there are more packages to maintain, over the one I 
> need to now.  

Yeah.  From a sysadmin perspective, super-modular projects like Xorg or
teTeX really make my life miserable - and I do not see particular gain
in moving things that are part of "the openvpn package" into separate 
projects.

(Windows TAP is fine, as it's really a project on its own, useful for
openvpn, but not that closely tied to it)

> HOWEVER, from the OpenVPN development process, I think it's best
> to split things out, as Alon suggests, with one caveat.  Let's wait
> for 3.0.  That's already going to be a massive change to our source
> tree and overall build process, and I think it would be the right
> time to push that out.

Even then.  Modular source doesn't mean everything gets fragmented in
500 teeny little packages where package maintainers or sysadmins have
to figure out which 395 of those they need, and which ones can be
skipped.

Try to build Xorg or teTeX yourself, from packages, and learn from it.

(Continue reading)

Alon Bar-Lev | 13 May 11:10 2012
Picon

Re: [RFC] Split plugins into their own repositories

On Sun, May 13, 2012 at 12:01 PM, Gert Doering <gert <at> greenie.muc.de> wrote:
> Try to build Xorg or teTeX yourself, from packages, and learn from it.

We are not xorg... [yet].
Anyway, I think the modular xorg and kde processes are a great success.
It allowed them to delegate maintenance, and handle shorter release
cycles for each component. Now people can update their xinit without
receiving ~50 unneeded changes. Stabilization process is also much
shorter now, as most of the components are static.

I showed Eric that the freebsd already maintains[1] the auth-radius,
auth-ldap in modular way. Not sure why the auth-pam and down-root are
any different.

We need to strive to join efforts with these other plugin maintainer,
hosting them on the openvpn project resources, and build healthy
community.

And, if not split, they these two plugins should integrated within
build system. The custom make files are not doing any good, but I
still don't understand the difference between these two and other
plugins out there.

Alon.

[1] http://www.freebsd.org/cgi/ports.cgi?query=openvpn&stype=all

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
(Continue reading)

Gert Doering | 13 May 11:23 2012
Picon

Re: [RFC] Split plugins into their own repositories

Hi,

On Sun, May 13, 2012 at 12:10:48PM +0300, Alon Bar-Lev wrote:
> And, if not split, they these two plugins should integrated within
> build system. 

This is certainly true.

> The custom make files are not doing any good, but I
> still don't understand the difference between these two and other
> plugins out there.

They are maintained by the openvpn project, and other plugins are not.

That difference should be quite obious, no?

gert
--

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert <at> greenie.muc.de
fax: +49-89-35655025                        gert <at> net.informatik.tu-muenchen.de
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
(Continue reading)

Alon Bar-Lev | 13 May 11:30 2012
Picon

Re: [RFC] Split plugins into their own repositories

On Sun, May 13, 2012 at 12:23 PM, Gert Doering <gert <at> greenie.muc.de> wrote:
> Hi,
>
> On Sun, May 13, 2012 at 12:10:48PM +0300, Alon Bar-Lev wrote:
>> And, if not split, they these two plugins should integrated within
>> build system.
>
> This is certainly true.
>
>> The custom make files are not doing any good, but I
>> still don't understand the difference between these two and other
>> plugins out there.
>
> They are maintained by the openvpn project, and other plugins are not.
>
> That difference should be quite obious, no?

This is exactly my point.

An healthy community dealing with openvpn need to gather all resources
that are acting at that niche.
There is no reason why we should not invite these maintainer to be
part of the openvpn project, on the contrary, we gain more resources,
more professionals.

Why should we define the scope of the openvpn project based on the
legacy james svn tree?
Can't we progress?

I would like to see this community growing... all UI/management/plugin
(Continue reading)

Gert Doering | 13 May 11:35 2012
Picon

Re: [RFC] Split plugins into their own repositories

Hi,

On Sun, May 13, 2012 at 12:30:37PM +0300, Alon Bar-Lev wrote:
> An healthy community dealing with openvpn need to gather all resources
> that are acting at that niche.
> There is no reason why we should not invite these maintainer to be
> part of the openvpn project, on the contrary, we gain more resources,
> more professionals.

And how exactly will "fragment the openvpn source tree into many small
packages" invite more contribution?

I, for one, will think twice about contributing to a project where I have
to figure out which of the 470 packages I need to download before I can
even *start* looking at things.

> Why should we define the scope of the openvpn project based on the
> legacy james svn tree?

Why not?

> Can't we progress?

Why is that progress?

Change always has drawbacks.  If the plus sides outweighs the drawbacks,
change is good.  Change for change's sake, "just because you can change
it", is not.

> I would like to see this community growing... all UI/management/plugin
(Continue reading)

Alon Bar-Lev | 13 May 13:00 2012
Picon

Re: [RFC] Split plugins into their own repositories

On Sun, May 13, 2012 at 12:35 PM, Gert Doering <gert <at> greenie.muc.de> wrote:
> Hi,
>
> On Sun, May 13, 2012 at 12:30:37PM +0300, Alon Bar-Lev wrote:
>> An healthy community dealing with openvpn need to gather all resources
>> that are acting at that niche.
>> There is no reason why we should not invite these maintainer to be
>> part of the openvpn project, on the contrary, we gain more resources,
>> more professionals.
>
> And how exactly will "fragment the openvpn source tree into many small
> packages" invite more contribution?
>
> I, for one, will think twice about contributing to a project where I have
> to figure out which of the 470 packages I need to download before I can
> even *start* looking at things.
>
>> Why should we define the scope of the openvpn project based on the
>> legacy james svn tree?
>
> Why not?
>
>> Can't we progress?
>
> Why is that progress?
>
> Change always has drawbacks.  If the plus sides outweighs the drawbacks,
> change is good.  Change for change's sake, "just because you can change
> it", is not.

(Continue reading)

Gert Doering | 13 May 13:12 2012
Picon

Re: [RFC] Split plugins into their own repositories

Hi,

On Sun, May 13, 2012 at 02:00:32PM +0300, Alon Bar-Lev wrote:
> >> Can't we progress?
> >
> > Why is that progress?
> >
> > Change always has drawbacks.  If the plus sides outweighs the drawbacks,
> > change is good.  Change for change's sake, "just because you can change
> > it", is not.
> 
> Yes, but still from your responses I don't see any drawback... maybe I
> am slow learner...

Drawback to maintainers and sysadmins has already been mentioned by
ecrist and me.  Try being a sysadmin for a few weeks and figure out
which bits of xorg you need to download to install xinit, assuming
you have a system without any X libraries and headers yet (in the xorg
example: splitting off "xinit" might actually make sense, but splitting
the basic infrastructure to build anything into about 50 different
"xyz-library" and "xyz-headers" packages is crazyness).

But the onus is not particularily on me: you have not put forward 
convincing arguments why splitting off a very small number of files 
that only make use in the context of OpenVPN into their own repository 
has any *advantage*.

The handwavy argument "it will attract more users!" can be countered by
similarily handwaving "I, as a user, hate to download multiple packages
to figure out how to start contributing, and so it will scare *away*
(Continue reading)

Alon Bar-Lev | 13 May 13:26 2012
Picon

Re: [RFC] Split plugins into their own repositories

On Sun, May 13, 2012 at 2:12 PM, Gert Doering <gert <at> greenie.muc.de> wrote:
> Hi,
>
> On Sun, May 13, 2012 at 02:00:32PM +0300, Alon Bar-Lev wrote:
>> >> Can't we progress?
>> >
>> > Why is that progress?
>> >
>> > Change always has drawbacks.  If the plus sides outweighs the drawbacks,
>> > change is good.  Change for change's sake, "just because you can change
>> > it", is not.
>>
>> Yes, but still from your responses I don't see any drawback... maybe I
>> am slow learner...
>
> Drawback to maintainers and sysadmins has already been mentioned by
> ecrist and me.  Try being a sysadmin for a few weeks and figure out
> which bits of xorg you need to download to install xinit, assuming
> you have a system without any X libraries and headers yet (in the xorg
> example: splitting off "xinit" might actually make sense, but splitting
> the basic infrastructure to build anything into about 50 different
> "xyz-library" and "xyz-headers" packages is crazyness).

First, I was gentoo developer for some time, and maintained, among
other, openvpn packages.
The case of xorg is not similar, you keep using this example while in
the openvpn case we have a core and a set of optional plugins, that's
all.
So please give appropriate example.

(Continue reading)

Gert Doering | 13 May 14:19 2012
Picon

Re: [RFC] Split plugins into their own repositories

Hi,

On Sun, May 13, 2012 at 02:26:05PM +0300, Alon Bar-Lev wrote:
> OK... now you are talking... so you say that like apache we need to
> integrate the plugins to main build system, this was the other
> alternative.

This would make more sense to me.  Either have them as optional
"configure" components, or just build and install all of them all 
the time.

If we ignore the examples, we really only have "auth-pam" and "down-root"
in the main distribution today, and those are useful in many cases - so
I'd go for "always build and install them".

gert
--

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert <at> greenie.muc.de
fax: +49-89-35655025                        gert <at> net.informatik.tu-muenchen.de
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
(Continue reading)

Alon Bar-Lev | 13 May 14:24 2012
Picon

Re: [RFC] Split plugins into their own repositories

On Sun, May 13, 2012 at 3:19 PM, Gert Doering <gert <at> greenie.muc.de> wrote:
> Hi,
>
> On Sun, May 13, 2012 at 02:26:05PM +0300, Alon Bar-Lev wrote:
>> OK... now you are talking... so you say that like apache we need to
>> integrate the plugins to main build system, this was the other
>> alternative.
>
> This would make more sense to me.  Either have them as optional
> "configure" components, or just build and install all of them all
> the time.
>
> If we ignore the examples, we really only have "auth-pam" and "down-root"
> in the main distribution today, and those are useful in many cases - so
> I'd go for "always build and install them".

And always have pam dependency for this example?
These plugins should be optional I don't see any value in enforcing
them and their dependencies.

Alon.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Openvpn-devel mailing list
(Continue reading)

Gert Doering | 13 May 15:07 2012
Picon

Re: [RFC] Split plugins into their own repositories

Hi,

On Sun, May 13, 2012 at 03:24:59PM +0300, Alon Bar-Lev wrote:
> > If we ignore the examples, we really only have "auth-pam" and "down-root"
> > in the main distribution today, and those are useful in many cases - so
> > I'd go for "always build and install them".
> 
> And always have pam dependency for this example?

FreeBSD, NetBSD, all Linuxes and Solaris have PAM anyway.

So make this "if pam libraries + headers are detected, install auth-pam, 
otherwise, not".

> These plugins should be optional I don't see any value in enforcing
> them and their dependencies.

If these plugins are useful for a large number of users, there is no
point in not installing them by default.

gert

--

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert <at> greenie.muc.de
fax: +49-89-35655025                        gert <at> net.informatik.tu-muenchen.de
------------------------------------------------------------------------------
(Continue reading)

Alon Bar-Lev | 13 May 15:10 2012
Picon

Re: [RFC] Split plugins into their own repositories

On Sun, May 13, 2012 at 4:07 PM, Gert Doering <gert <at> greenie.muc.de> wrote:
> Hi,
>
> On Sun, May 13, 2012 at 03:24:59PM +0300, Alon Bar-Lev wrote:
>> > If we ignore the examples, we really only have "auth-pam" and "down-root"
>> > in the main distribution today, and those are useful in many cases - so
>> > I'd go for "always build and install them".
>>
>> And always have pam dependency for this example?
>
> FreeBSD, NetBSD, all Linuxes and Solaris have PAM anyway.
>
> So make this "if pam libraries + headers are detected, install auth-pam,
> otherwise, not".

We already discussed the automatic detection and integrity failure as result.

>
>> These plugins should be optional I don't see any value in enforcing
>> them and their dependencies.
>
> If these plugins are useful for a large number of users, there is no
> point in not installing them by default.

They are not.
Exactly because the are not useful, I am for the split.
Anyway, if you follow the apache example there is explicit
enable/disable to each.

BTW: Packager of what platform are you?
(Continue reading)

Gert Doering | 13 May 20:10 2012
Picon

Re: [RFC] Split plugins into their own repositories

Hi,

On Sun, May 13, 2012 at 04:10:54PM +0300, Alon Bar-Lev wrote:
> >> And always have pam dependency for this example?
> >
> > FreeBSD, NetBSD, all Linuxes and Solaris have PAM anyway.
> >
> > So make this "if pam libraries + headers are detected, install auth-pam,
> > otherwise, not".
> 
> We already discussed the automatic detection and integrity failure as result.

Huh?  You're the master of Autoconf, and I'm sure you will be able to
produce a working PAM detection for those platforms that have it.

> >> These plugins should be optional I don't see any value in enforcing
> >> them and their dependencies.
> >
> > If these plugins are useful for a large number of users, there is no
> > point in not installing them by default.
> 
> They are not.

Unfounded claim.

> Exactly because the are not useful, I am for the split.
> Anyway, if you follow the apache example there is explicit
> enable/disable to each.

And there are some that are enabled by default.  Your point?
(Continue reading)

Alon Bar-Lev | 13 May 20:23 2012
Picon

Re: [RFC] Split plugins into their own repositories

On Sun, May 13, 2012 at 9:10 PM, Gert Doering <gert <at> greenie.muc.de> wrote:
> Hi,
>
> On Sun, May 13, 2012 at 04:10:54PM +0300, Alon Bar-Lev wrote:
>> >> And always have pam dependency for this example?
>> >
>> > FreeBSD, NetBSD, all Linuxes and Solaris have PAM anyway.
>> >
>> > So make this "if pam libraries + headers are detected, install auth-pam,
>> > otherwise, not".
>>
>> We already discussed the automatic detection and integrity failure as result.
>
> Huh?  You're the master of Autoconf, and I'm sure you will be able to
> produce a working PAM detection for those platforms that have it.

Yes, and as such I tell you that automatic detection is something that
leads to package breakage.
We already discussed that in the lzo subject.
I know you are fundamentally against any change, but I think I proved
very well that I actually know what I am doing.

>
>> >> These plugins should be optional I don't see any value in enforcing
>> >> them and their dependencies.
>> >
>> > If these plugins are useful for a large number of users, there is no
>> > point in not installing them by default.
>>
>> They are not.
(Continue reading)

Fabian Knittel | 13 May 21:52 2012
Picon

Re: [RFC] Split plugins into their own repositories

Hi Alon,

2012/5/13 Alon Bar-Lev <alon.barlev <at> gmail.com>:
> On Sun, May 13, 2012 at 9:10 PM, Gert Doering <gert <at> greenie.muc.de> wrote:
>> Huh?  You're the master of Autoconf, and I'm sure you will be able to
>> produce a working PAM detection for those platforms that have it.
>
> Yes, and as such I tell you that automatic detection is something that
> leads to package breakage.

How does PAM detection relate to the question whether to split out the
plugin? Wouldn't the plugin's configure also need to detect PAM? As
already discussed previously, I much prefer configure to notice a
missing development package than to run into a failing "make" run.

And why would automatic pam detection lead to package breakage? Have
an option for enabling / disabling plugins. If a plugin is enabled and
needs PAM, check for the existence of PAM. If PAM isn't found, exit
configure and tell the user to pass the proper paths for pam headers
and libraries.

>>> >> These plugins should be optional I don't see any value in enforcing
>>> >> them and their dependencies.
>>> >
>>> > If these plugins are useful for a large number of users, there is no
>>> > point in not installing them by default.
>>>
>>> They are not.
>>
>> Unfounded claim.
(Continue reading)

Gert Doering | 13 May 22:39 2012
Picon

Re: [RFC] Split plugins into their own repositories

Hi,

On Sun, May 13, 2012 at 09:23:04PM +0300, Alon Bar-Lev wrote:
> > Huh?  You're the master of Autoconf, and I'm sure you will be able to
> > produce a working PAM detection for those platforms that have it.
> 
> Yes, and as such I tell you that automatic detection is something that
> leads to package breakage.
> We already discussed that in the lzo subject.

We're not talking about extra libraries that might or might not be there -
on all systems I named, PAM is part of the basic operating system, as
is "libc" or one of the zillion header files that you're currently testing
for.

> I know you are fundamentally against any change, but I think I proved
> very well that I actually know what I am doing.

Now you are the one who is opposing change.  You asked what we want, and
if the plugins should not be split, how the build system should be adapted.

This is what I answered: if we want to adapt the build system for the
plugins, compile them by default, and install them.  And now you're finding
reasons why this is bad.

Fine, leave it at that - there's quite obviously not much support for the
split, and since you do not want to compile & install by default, nobody
can force you to implement that.

> >> >> These plugins should be optional I don't see any value in enforcing
(Continue reading)

Seth Mos | 15 May 09:34 2012
Picon

Re: [RFC] Split plugins into their own repositories

Op 13-5-2012 20:23, Alon Bar-Lev schreef:
> On Sun, May 13, 2012 at 9:10 PM, Gert Doering<gert <at> greenie.muc.de>  wrote:

> Come on! most of installations are plain public key without any of
> these plugins.
> There is no need for these if you configure your server.
> I simply don't understand your attitude... sorry, I simply don't.

Please note that we include OpenVPN in the pfSense product, and we 
pretty much provide access to a huge number of options in the UI.

There are quite a lot of installs out there that use OpenVPN with 
certificates and Radius authentication.

Regardless, we need to ship with pretty much all options enabled. We are 
not going to ship 15 images to get all the options. And letting users 
install other "packages" to get the features seems silly.

We're not a OpenWRT where the small memory footprint is limiting what 
you can do.

So just because most users don't use the other features that makes it a 
valid argument? Ehm. not sure on that.

Cheers,

Seth

------------------------------------------------------------------------------
Live Security Virtual Conference
(Continue reading)

Alon Bar-Lev | 15 May 09:38 2012
Picon

Re: [RFC] Split plugins into their own repositories

On Tue, May 15, 2012 at 10:34 AM, Seth Mos <seth.mos <at> dds.nl> wrote:
> Op 13-5-2012 20:23, Alon Bar-Lev schreef:
>> On Sun, May 13, 2012 at 9:10 PM, Gert Doering<gert <at> greenie.muc.de>  wrote:
>
>> Come on! most of installations are plain public key without any of
>> these plugins.
>> There is no need for these if you configure your server.
>> I simply don't understand your attitude... sorry, I simply don't.
>
> Please note that we include OpenVPN in the pfSense product, and we
> pretty much provide access to a huge number of options in the UI.
>
> There are quite a lot of installs out there that use OpenVPN with
> certificates and Radius authentication.
>
> Regardless, we need to ship with pretty much all options enabled. We are
> not going to ship 15 images to get all the options. And letting users
> install other "packages" to get the features seems silly.
>
> We're not a OpenWRT where the small memory footprint is limiting what
> you can do.
>
> So just because most users don't use the other features that makes it a
> valid argument? Ehm. not sure on that.
>
> Cheers,
>
> Seth

So basically what you want is to use adding the auth radius into the
(Continue reading)

Seth Mos | 13 May 13:40 2012
Picon

Re: [RFC] Split plugins into their own repositories

Chiming in here,

Although pfSense is basically a giant tarbal, it has the benefit of being sure that all parts of it fit
together. We also have installable packages and we frequently see issues with that. We are trying to solve
some of them using PBI packages just so that each "package" always has it's dependencies in check.

Although we are just a "consumer", we'd rather have a single FreeBSD port that we build then 5 ports we need to
update, with all the required dependencies.

Our github repo is split into one for packages, tools and pfSense. But each is really a standalone thing,
because there is no overlap. Which probably my point, the plugin is useless without the main.

The one git repo for pfSense is pretty manageable, even more so through git with Pull requests. The single
biggest jump in commits and patches from the community is moving to GitHub. It makes contributions so much
easier. That said, even for us the amount of simultaneous active coders is about 5, although we do see small
patches and pull requests from about 30 or so people a year.

I see nagios using nagios-plugins, that has seperate releases from the main nagios. So there's that too.

Just a few thoughts from the other end.

Really, really, _really_ looking forward to Viscosity and Tunnelblick shipping Ipv6 enabled clients.
Pretty please.

Cheers,

Seth
pfSense developer

Op 13 mei 2012, om 13:12 heeft Gert Doering het volgende geschreven:
(Continue reading)

Alon Bar-Lev | 13 May 13:49 2012
Picon

Re: [RFC] Split plugins into their own repositories

Hello Seth,

Thank you this is interesting.

I don't know pfSense... do you have the nation of plugin which is
independent from the core?
I mean pre-defined interface, which is backward compatible?
I looked briefly on the source tree and did not find my way...

A counter example of nagios is cacti... which provides plugins as
their own... :)

So basically you think that openvpn or openvpn-plugin package should
install all plugins, and depend on the union of all, right?

Alon.

On Sun, May 13, 2012 at 2:40 PM, Seth Mos <seth.mos <at> dds.nl> wrote:
> Chiming in here,
>
> Although pfSense is basically a giant tarbal, it has the benefit of being sure that all parts of it fit
together. We also have installable packages and we frequently see issues with that. We are trying to solve
some of them using PBI packages just so that each "package" always has it's dependencies in check.
>
> Although we are just a "consumer", we'd rather have a single FreeBSD port that we build then 5 ports we need
to update, with all the required dependencies.
>
> Our github repo is split into one for packages, tools and pfSense. But each is really a standalone thing,
because there is no overlap. Which probably my point, the plugin is useless without the main.
>
(Continue reading)

Eric Crist | 13 May 21:42 2012
Picon

Re: [RFC] Split plugins into their own repositories

What I had mentioned might be a good alternative in IRC was to have an openvpn package, and an
openvpn-contrib.  Two isn't hard, 17 or 500 is.  This, still, didn't seem to be liked by Alon (not calling you
out, per se, but stating fact).

Not sure where we should go from here other than to stay where we are.  No point in moving until we're all ready
to move in the same direction.  If need be, we can enforce a dev-team sack race when we next get together. ;)

-----
Eric F Crist

On May 13, 2012, at 07:40:07, Seth Mos wrote:

> Chiming in here,
> 
> Although pfSense is basically a giant tarbal, it has the benefit of being sure that all parts of it fit
together. We also have installable packages and we frequently see issues with that. We are trying to solve
some of them using PBI packages just so that each "package" always has it's dependencies in check.
> 
> Although we are just a "consumer", we'd rather have a single FreeBSD port that we build then 5 ports we need
to update, with all the required dependencies.
> 
> Our github repo is split into one for packages, tools and pfSense. But each is really a standalone thing,
because there is no overlap. Which probably my point, the plugin is useless without the main.
> 
> The one git repo for pfSense is pretty manageable, even more so through git with Pull requests. The single
biggest jump in commits and patches from the community is moving to GitHub. It makes contributions so much
easier. That said, even for us the amount of simultaneous active coders is about 5, although we do see small
patches and pull requests from about 30 or so people a year.
> 
> I see nagios using nagios-plugins, that has seperate releases from the main nagios. So there's that too.
(Continue reading)

Eric Crist | 13 May 21:49 2012
Picon

Re: [RFC] Split plugins into their own repositories

David,

You misrepresent my opinion.  I do NOT want a split, but will deal with one (as a packager) if it becomes
necessary.  I would much prefer there to never be a split, and for everything to be handled with configure
args or ifdefs in the make file.

-----
Eric F Crist

On May 13, 2012, at 15:42:10, Eric Crist wrote:

> What I had mentioned might be a good alternative in IRC was to have an openvpn package, and an
openvpn-contrib.  Two isn't hard, 17 or 500 is.  This, still, didn't seem to be liked by Alon (not calling you
out, per se, but stating fact).
> 
> Not sure where we should go from here other than to stay where we are.  No point in moving until we're all ready
to move in the same direction.  If need be, we can enforce a dev-team sack race when we next get together. ;)
> 
> -----
> Eric F Crist
> 
> 
> 
> On May 13, 2012, at 07:40:07, Seth Mos wrote:
> 
>> Chiming in here,
>> 
>> Although pfSense is basically a giant tarbal, it has the benefit of being sure that all parts of it fit
together. We also have installable packages and we frequently see issues with that. We are trying to solve
some of them using PBI packages just so that each "package" always has it's dependencies in check.
(Continue reading)

Samuli Seppänen | 15 May 09:23 2012
Picon

Re: [RFC] Split plugins into their own repositories


> My two cents on this is as follows:
>
> As a package maintainer, I think this is going to prove to be a lot of work.  It means there are more packages to
maintain, over the one I need to now.  HOWEVER, from the OpenVPN development process, I think it's best to
split 
Yes, unless we can move the plugin packaging tasks to other people. That
would be easier with separated plugins, but still a big "if". Perhaps I
should ask if somebody's willing to take over this challenge...

Samuli

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
David Sommerseth | 13 May 20:11 2012
Picon

Re: [RFC] Split plugins into their own repositories - Discussion Summary


On 06/05/12 18:55, Alon Bar-Lev wrote:
> Hello,
> 
> Now, I also have the courage to ask one more question regarding 
> build....
> 
> We currently have: - auth-pam - defer - down-root - examples

I'm just giving a summary here of the discussion, how I see the
discussion.  And hope we can close this one soon.  The thread is
long and many of the arguments are repeated several times.

Basically, the situation is as now:

Those who opposes a split now are Adriaan, Gert and I, which are all
active with development in the tree.  Seth has also voted against.
And Eric says "not before v3.0".

Those in favour are Alon, Samuli and Eric after v3.0.

----------------------------------------------

Then let's look at the commit history for these plug-ins which are
discussed.  The git log goes back to the old BETA21 SVN branch.

auth-pam/auth-pam.c   - 17 changes
auth-pam/pamdl.c      -  7 changes
auth-pam/pamdl.h      -  6 changes
down-root/down-root.c - 12 changes
(Continue reading)

Alon Bar-Lev | 13 May 20:31 2012
Picon

Re: [RFC] Split plugins into their own repositories - Discussion Summary

On Sun, May 13, 2012 at 9:11 PM, David Sommerseth
<openvpn.list <at> topphemmelig.net> wrote:
> So, please!  Can we rather spend our precious time and energy to fix
> *real* bugs?   <https://community.openvpn.net/openvpn/report/1>

I would like to spend time in completing the order of build/packaging,
a task I started and would like to end, giving all my experience at
that subject, which is quite large.

BTW: krzee (user) at IRC also in favor of split, I also contacted
debian and rpmforge openvpn package maintainer for their views on this
matter.

Except of Eric, nobody is distro maintainer, and after short talk to
Eric, he does not realize that 3.0 is not going to happen any time
soon.

> And this is the last thing I'm going to say in this discussion.

This is not the way to do discussion.
So what now... you decide you enforce? as you are the only one that can commit?

Alon.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
(Continue reading)

David Sommerseth | 14 May 14:22 2012
Picon

Re: [RFC] Split plugins into their own repositories - Discussion Summary


On 13/05/12 20:31, Alon Bar-Lev wrote:
>>> And this is the last thing I'm going to say in this
>>> discussion.
> 
> This is not the way to do discussion. So what now... you decide you
> enforce? as you are the only one that can commit?

No, I am not enforcing anything.  I'm pulling myself out of this
discussion.  And as there is no patch here, just an RFC, there is
nothing to apply or commit.

I think the majority of the discussion has been repeating itself, the
later replies have not been a fruitful discussion at all and has not
provided any new discussion points which really changes the
situation/opinions.

And I am really not happy about the tone some of the replies have
taken.  It feels like there is some disrespect to others opinions than
respect.

Considering that you sent an RFC, the majority of the replies have
been more in favour of not doing a split vs doing the split; And you
have received comments to your request.

Fair enough, you are allowed to discuss and argue for you point of
view - and I don't want to restrict your freedom here.  But the bottom
line is: it has not moved the opinion of anyone.

All in all, I see no reason to continue participating in this
(Continue reading)


Gmane