Unbundling Commons Daemon and tcnative

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Unbundling Commons Daemon and tcnative

Michael Osipov
Guys,

I have been wondering recently why are we bundling
commons-daemon-native.tar.gz and tomcat-native.tar.gz every time with a
new release at all?

There are two scenarios where people don't require to use it from the
tarball:

1. Tomcat Native and Commons Daemon are installed through OS package or
port. Thus making the bundling redundant. E.g., on RHEL, Fedora, *BSD,
etc. => OS managed
2. Both are compiled from source and survive Tomcat updates because
there are installed outside of Tomcat, e.g., in /usr/local or
/opt/ports, etc. These people don't need those tarballs too because they
get them from dist.apache.org. => manually managed

I do both approaches on different operating systems.

We can say/document that Tomcat release T requires libtcnative x.y.z and
Commons Daemon a.b.c to run, get your own from dist.apache.org if you do
it manually.

More confusing is that apache-tomcat-8.5.48-dev-windows-*.zip bundles
tcnative-1.dll (which is huge in size, OpenSSL statically linked?) *and*
the source tarball, same for Commons Daemon. Why?

Opinions?

Michael

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Unbundling Commons Daemon and tcnative

markt
On 09/10/2019 17:36, Michael Osipov wrote:
> I have been wondering recently why are we bundling
> commons-daemon-native.tar.gz and tomcat-native.tar.gz every time with a
> new release at all?

Because users find it convenient to have the latest versions available.

> There are two scenarios where people don't require to use it from the
> tarball:
>
> 1. Tomcat Native and Commons Daemon are installed through OS package or
> port. Thus making the bundling redundant. E.g., on RHEL, Fedora, *BSD,
> etc. => OS managed

In that case I'd expect Tomcat to be installed via an OS package or port
which makes any redundancy the packager's responsibility. If users want
to mix packaged and direct download then I think it is fair to expect
them to deal with a little redundancy - especially when they just have
to ignore/delete a couple of files.

> 2. Both are compiled from source and survive Tomcat updates because
> there are installed outside of Tomcat, e.g., in /usr/local or
> /opt/ports, etc. These people don't need those tarballs too because they
> get them from dist.apache.org. => manually managed
>
> I do both approaches on different operating systems.
>
> We can say/document that Tomcat release T requires libtcnative x.y.z and
> Commons Daemon a.b.c to run, get your own from dist.apache.org if you do
> it manually.

I think that is less convenient for users.

> More confusing is that apache-tomcat-8.5.48-dev-windows-*.zip bundles
> tcnative-1.dll (which is huge in size, OpenSSL statically linked?)

Yes, OpenSSL (as well as APR) is statically linked.

> *and* the source tarball, same for Commons Daemon. Why?

On Windows I think there is a case for not shipping the native sources
since the binaries are already present. Asking a user who wants them to
download them seems reasonable in that instance.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Unbundling Commons Daemon and tcnative

Michael Osipov
Am 2019-10-09 um 19:14 schrieb Mark Thomas:
> On 09/10/2019 17:36, Michael Osipov wrote:
>> I have been wondering recently why are we bundling
>> commons-daemon-native.tar.gz and tomcat-native.tar.gz every time with a
>> new release at all?
>
> Because users find it convenient to have the latest versions available.

I already expected this, but any other reason?

>> There are two scenarios where people don't require to use it from the
>> tarball:
>>
>> 1. Tomcat Native and Commons Daemon are installed through OS package or
>> port. Thus making the bundling redundant. E.g., on RHEL, Fedora, *BSD,
>> etc. => OS managed
>
> In that case I'd expect Tomcat to be installed via an OS package or port
> which makes any redundancy the packager's responsibility. If users want
> to mix packaged and direct download then I think it is fair to expect
> them to deal with a little redundancy - especially when they just have
> to ignore/delete a couple of files.

Most OSes won't deliver an up to date Tomcat, so expect mixing. Yes,
redundancy is OK here.

>> 2. Both are compiled from source and survive Tomcat updates because
>> there are installed outside of Tomcat, e.g., in /usr/local or
>> /opt/ports, etc. These people don't need those tarballs too because they
>> get them from dist.apache.org. => manually managed
>>
>> I do both approaches on different operating systems.
>>
>> We can say/document that Tomcat release T requires libtcnative x.y.z and
>> Commons Daemon a.b.c to run, get your own from dist.apache.org if you do
>> it manually.
>
> I think that is less convenient for users.

That is true, but would also reduce the binary artifacts.

>> *and* the source tarball, same for Commons Daemon. Why?
>
> On Windows I think there is a case for not shipping the native sources
> since the binaries are already present. Asking a user who wants them to
> download them seems reasonable in that instance.

Shall I create an enhancement request for this?

Michael

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Unbundling Commons Daemon and tcnative

markt
On 09/10/2019 21:34, Michael Osipov wrote:
> Am 2019-10-09 um 19:14 schrieb Mark Thomas:
>> On 09/10/2019 17:36, Michael Osipov wrote:
>>> I have been wondering recently why are we bundling
>>> commons-daemon-native.tar.gz and tomcat-native.tar.gz every time with a
>>> new release at all?
>>
>> Because users find it convenient to have the latest versions available.
>
> I already expected this, but any other reason?

None that I can think of at the moment.

>> On Windows I think there is a case for not shipping the native sources
>> since the binaries are already present. Asking a user who wants them to
>> download them seems reasonable in that instance.
>
> Shall I create an enhancement request for this?

Yes please.

Thanks,

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]