Hi Jyri, Attached is a revised (single) Arc Case that brings together both the proposed changes to the existing Lighttpd packages and the proposal of the addition of the new SUNWspawn-fcgi package. I believe it addresses all of your points.
Regards Amanda Jyri Virkki wrote: > Amanda Waite wrote: > >>>> - 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 >> > > Ah, but the set of public interfaces are for the system as a > whole. The key is not whether you're removing spawn-fcgi from the > lighttpd package, it is whether you're removing it from OpenSolaris: > > Today OpenSolaris provides lighttpd and a spawn-fcgi which works with it. > Unless I'm missing some key detail, after these changes go in, none of > that changes. No functionality or feature goes away, so all remains as > it was as far as the available interfaces are concerned. > > All that is happening is a refactoring of a file (or files) from one > package to a different package, no interfaces are being obsoleted or > removed. > > (Well, except for the one symlink which is being declared obsolete, > smaller detail.) > > > >>> 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. >> > > Please add a section in the case discussing the upgrade scenario > (basically, what you say above) as it is an important consideration > for the ARC case. > > If at all possible, the implementation should log a warning on startup > when it sees this now-obsolete configuration directive, to actively > warn users that they need to migrate away from using it. > > The manpage should also have commentary along those lines. > > > >>> 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. >> > > Understood. Question is what's the impact when it happens, though? > i.e. is the full path typically encoded in customers configurations > and/or shell scripts and/or elsewhere. Or maybe the answer is nothing > much happens? > > (This case doesn't necessarily have to answer those questions because > it is not removing the symlink, only marking it Obsolete. But if the > info is available, doesn't hurt.) > > > >>> 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. >> > > That alone isn't the reason, there's nothing fundamentally wrong about > having the symlink as long as lighttpd package depends on spawn-fcgi > package (thus guaranteeing the target of the link is present). > > I'm curious if there is, and if so what is it, a technical or > usability reason why the link is best eliminated in the future. I > suspect this is a minor point and not terribly important one way or > the other. Still curious though. > > (As above, this case doesn't really need to answer that since it is > not removing, only Obsoleting.. but if you happen to know..) > > > >> 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. >> > > (Well, no, since the file is simply being refactored from one package > to the other one. Anyway, no matter here.) > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Lighttpd-spawn.txt URL: <http://mail.opensolaris.org/pipermail/webstack-discuss/attachments/20091013/ec71c996/attachment.txt>
