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.) -- Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
