Are we good to go with these Arc cases or do I need to drop OpenLDAP support for now? I really would like to get the main work done ASAP rather than end up having to rush to meet a code freeze deadline.
Thanks a bunch Amanda Amanda Waite wrote: > 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 > > > _______________________________________________ > > > webstack-discuss mailing list > webstack-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
