Jyri Virkki wrote: > Amanda Waite wrote: > >> Attached is the draft Arc case for updating Lighttpd in SFW. I felt this >> was needed as it covers the following: >> >> - Obsolescence of spawn-fcgi in the Lighttpd packages >> > > The key question is, is any supported functionality or public interface > of spawn-fcgi is changing or going away (location aside)? >
Yes, spawn-fcgi is, it doesn't make sense not to remove spawn-fcgi from Lighttpd > As noted in the case, the lighttpd package will depend on the > spawn-fcgi package, so as far as the user is concerned do they still > get all the same functionality when installing lighttpd? > Yes, that has to be the case as the interfaces are uncommitted. The only way I can remove them is through the obsolescence process. > > > >> - Addition of OpenLDAP and Lua as imported interfaces >> > > See the OpenLDAP thread for comments on importing it from lighttpd. > > > >> 2.4 Changes to the configuration file >> >> At the request of the upstream Lighttpd community this case will remove >> the line: >> >> server.max-workers = 4 >> >> From the Lighttpd configuration file. Running Lighttpd with multiple >> workers is not supported by the upstream community. >> > > What about upgrades? Will upgrading previous installation of lighttpd > with this future package remove (or ignore) max-workers or will it > continue to work as before? If the latter, does that now lead to an > unsupported scenario or do you expect to continue supporting it (for > upgrading users only)? > The config file is marked in the package as preserve=renamenew, so it won't be clobbered in an upgrade. We'll need to take the use of more than one Lighttpd worker on a case by case basis. If a user reports an issue that is fixed by not running with multiple workers, then we'll have to inform them that they will need to modify their setup so that they no longer run into the issue, either by moving to a single worker setup or by not using modules that are affected by the issue. In the mean time we need to a) communicate that use of multiple workers is not supported and b) get a better understanding of the impact of only running with a single worker (particularly on CMT boxes). The first step has to be to remove the line from the config file, we can't be seen to be encouraging it's use, but we can't do that retrospectively. > > > >> The Lighttpd SUNWlighttpd14u package will include a dependency >> on the spawn-fcgi package and will provide symbolic links from >> the existing locations of the executable and manpage to the >> locations delivered by the spawn-fcgi package, i.e.: >> >> /usr/lighttpd/1.4/bin/spawn-fcgi -> /usr/bin/spawn-fcgi >> > > So looks like only the /usr/lighttpd/1.4/bin/spawn-fcgi path is being > obsoleted? > Yes > What will be the future impact on users when the symlink goes away in > a future release of lighttpd? > We have a year to communicate the message that this path is going away. > Alternatively, does the symlink need to go away? Is there a benefit to > continue to carry the symlink indefinitely? Does it make users life > easier in the long run or is it itself an oddity (i.e. all Linux users > are expecting /usr/bin/spawn-fcgi anyway) in which case it is good to > get it on the obsolete road. > Yes, the link needs to go. Lighttpd and spawn-fcgi are separate entities and there is no reason for the Lighttpd package to maintain links to the spawn-fcgi binary. Most other distros distribute spawn-fcgi as /usr/bin/spawn-fcgi and have done for some time (before the lighttpd/spawn-fcgi split). We kind of lucked out, because if we had originally installed spawn-fcgi to /usr/bin/spawn-fcgi we would now have a problem where two packages: current SUNWlighttpd14u and new spawn-fcgi, would be installing to the same path. Thanks for the comments Amanda
