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