Jeff Trawick wrote: > Amanda Waite wrote: >> Hi there, >> >> Attached is a very early draft of the Lighttpd 1.4.23 Arc Case. There >> is an issue that needs to be resolved before I take it forward and it >> would be useful to get everyone's input first. >> >> Lighttpd 1.4.23 no longer includes the spawn-fcgi utility which is >> broken out into a separate source distribution. I therefore seem to >> have 3 options: >> >> - break out spawn-fcgi into a separate SFW package > (thinking out loud) > > First I wonder: > * Why did the Lighttpd group split these out? Is it because > spawn-fcgi needed to release more often, or because it is not needed > by many/most Lighttpd users, or ???
For some it has utility outside of Lighttpd 1.4 anything that can talk sockets/UDS and the FCGI protocol could use the backends started by spawn-fcgi. It really made no sense for the two to be tied at the hip. > > This seems to answer most aspects: > http://blog.lighttpd.net/articles/2009/04/03/spawn-fcgi-removed-from-lighttpd-1-4 > > > > (It needed to release more often; Lighttpd is able to start FastCGI > processes without using spawn-fcgi.) >> - somehow build SUNWlighttp14u from two source distributions >> - remove spawn-fcgi from SUNWlighttpd14u > > What is the difference between option 1 and option 3? In terms of SUNWlighttpd* then nothing. For spawn-fcgi itself then option 1 means that it will still be available and option 3 means it won't. >> >> Option 1 probably requires option 3 and as it usually takes a year to >> remove an interface from a committed component it would also require >> cooperation from the ARC, allowing us to effectively maintain the >> same functionality in Lighttpd in SFW by making the spawn-fcgi >> package a dependency. >> >> Option 2 is easy on paper, but I suspect that it's unlikely to be >> supported by SFW who would ultimately love to be able to pull down >> the sources as required rather than store them, and as METADATA only >> has room for one source URL this then becomes difficult. Anyone know >> of any packages built from two source tarballs? > > Beyond what SFW wants: > > Having more than one open source package in a single OS package means > that some of the open source version information is lost. > > For example, where's the mod_perl version below? > > $ pkg list SUNWapch22 > NAME (PUBLISHER) VERSION > STATE UFIX > SUNWapch22 2.2.11-0.111 > installed ---- Fair point, same with RubyGems (and I really wish they had done that differently). I doubt if Option 2 would fly anyway and it's not the most sensible solution. Amanda > > _______________________________________________ > > > webstack-discuss mailing list > webstack-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/webstack-discuss
