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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to