You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Michael Osipov <mi...@apache.org> on 2019/10/09 16:36:37 UTC
Unbundling Commons Daemon and tcnative
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Unbundling Commons Daemon and tcnative
Posted by Mark Thomas <ma...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Unbundling Commons Daemon and tcnative
Posted by Michael Osipov <mi...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Unbundling Commons Daemon and tcnative
Posted by Mark Thomas <ma...@apache.org>.
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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org