Thanks for the input Jyri, I'll take everyones comments, suggestions and instructions offline, do some research and come back with an updated Arc Case in a couple of days.
Thanks all Amanda Jyri Virkki wrote: > Amanda Waite wrote: > >> Attached is a draft Arc Case for Lighttpd integration into Solaris. I >> notice that many Arc cases say "into Solaris" and not "into OpenSolaris" >> or "into Nevada" or "into SXCE" and I'm not sure what the correct choice >> of words is. >> > > I doubt anyone will nitpick that level of detail.. Anyway SXCE would > be the least correct. My favorite for open cases is "into OpenSolaris" > since we're on opensolaris.org after all. > > >> This is my first Arc Case so please feel free to tear it to shreds. I've >> done a good amount of due diligence in preparing this, but there are >> certainly things that I've missed and things that I've probably just got >> plain wrong. >> > > Ok I'll try to increase the level of verbosity on the nitpicking and > point out things I might let slide elsewhere ;-) > > >> This FastTrack delivers Lighttpd 1.4.x into the Solaris >> > > It's more correct to write "This project delivers ..." > > You may hope it is a Fast Track but what if ARC derails it? Then it > is no longer a Fast Track so now the sentence is wrong. > > > >> 2. Technical issues >> >> 2.1. Key objects >> >> /usr/sbin/lighttpd >> /usr/sbin/lighttpd-angel >> > > I saw the thread on sbin.. > > filesystem(5) says: > > /usr/sbin > > Platform-dependent executables for system administra- > tion, expected to be run only by system administrators. > An approved installation location for bundled Solaris > software. The analogous location for add-on system > software or for applications is /opt/packagename/sbin. > > As mentioned earlier daemon binaries don't really go in /usr/bin or > /usr/sbin since they're not executed directly. The public interface is > typically only "svcadm enable foo" and it'll know what to do. > > The thread said it is common to run lighttpd from the command line > manually? How universal is that practice? What's the reasoning? Does > it really apply here? > > So you face the competing goals of being consistent within OpenSolaris > vs. being consistent with the customs of a particular community. Never > an easy goal if there are differences. > > For the case materials: whichever approach you take, whenever there is > something controversial like this you'll want to have a paragraph or > two in the spec explaining both sides and the reasoning that led to > making the choice that you make. That way you don't have to answer the > same question for every reader that comes along and, more importantly, > the facts & reasoning are recorded for future reference. > > > >> /usr/bin/spawn-fcgi >> > > Is this really something that belongs in /usr/bin? > > > >> /usr/lighttpd/lib/mod_*.la >> /usr/lighttpd/lib/mod_*.so >> > > I saw the thread of removing *la so update that. > > >> 2.3 Loadable Modules >> >> Lighttpd ships with a number of loadable modules the usability >> of which depends on what features Lighttpd was built with. These >> > > The above sentence is confusing. It seems to be saying there's modules > shipped that may not work if the right options weren't compiled in? Is > that really true here? Is this case shipping modules that don't work? > Or is the sentence just misleading? > > >> 2.4 Directory Naming and Structure >> >> The proposed directory layout for Lighttpd is: >> >> /usr/bin >> /usr/sbin >> /usr/lighttpd >> > > Nit: Keep formatting lined up, easier to read and looks better. > > Don't list "/usr/bin", "/usr/sbin" dirs here, we know they exist.. > > >> 2.6 Configuration File >> >> The standard convention for configuration file location is >> /etc/lighttpd. >> > > Looking at the list later clarifies it, but just reading the above > it's not clear whether that is a directory or just a file in /etc > > >> This location is proposed for the Web Stack integration. The default >> > > "for the Web Stack integration" isn't the best phrasing (because "Web > Stack" isn't a thing that's integrating nor something lighttpd can > integrate into... it's just the name of this community). > > Just say "This project will use the standard convention and deliver > config files under /etc/lighttpd/". > > >> 2.8 SMF support >> >> If the packaging allows (bearing in mind that lighttpd will also be >> available as an IPS package, Lighttpd will be integrated into SMF and >> the appropriate manifest and method files will be provided in the >> package. >> > > I'm not sure what "If the packaging allows" means here? But yes, it > must be hooked into smf so it is possible to enable/disable/etc via > smf. The service name is a public interface so add it in the exported > interface table. If there are any smf properties(?) those are also > exported interfaces. > > Also, provide RBAC support so it is possible to delegate the smf > administration to some user by assigning them a rights profile. See > apache for an example to imitate (or postgres or mysql). > > >> 2.9 Build features >> >> > [...] > >> [TBC] List of configure options to be used for building Lighttpd >> for the integration: >> > > For the ARC case, documenting the build flags is a bit too low-level > (though it's certainly ok and informative to have them in the > appendix). The main concern is to document the features/interfaces > which will be available as a result of the chosen build flags, not so > much the names of the build flags themselves. > > > >> 4. Packaging and Delivery >> >> Lighttpd is delivered as the SUNWlhttpd package >> > > Why "lhttpd"? Overly abbreviated names make packages too difficult to > find. I suggest SUNWlighttpd[r|u]. > > As noted in the thread, unfortunately, it'll need separate packages > for /usr and non-/usr content (which in Indiana distro will be combined > right back anyway so it's a waste of time, but one of those rough > edges we have to deal with for now). > > Look at all the existing packages, you'll see various conventions for > the naming. The vast majority of packages seem to go with "r","u" > ending. I prefer that since it is less obtrusive, given the r/u > distinction is moot anyway. > > >> 5.1. Interface Stability >> >> Lighttpd has no obvious history of any interface instability and has >> been rock solid since we've worked with it (v 1.4.15) >> > > "rock solid" suggests lack of crashes, which isn't about interfaces. > > In s.2.2 it documents the stability expectations. Are these based on > stated intent from the lighttpd community or from observation? > Document the source. > > s2.2 says 1.5 might not be compatible. Which means OpenSolaris might > be stuck at lighttpd 1.4.* for a very very long time if an > incompatible 1.5 comes out, given that there is no package/dir > versioning and the interfaces are Uncommitted. > > One option is to do as apache/php/mysql have done and introduce some > versioning. If 1.5 is likely to be incompatible, perhaps you need > SUNWlighttpd14. If 1.* are expected to be compatible, maybe > SUNWlighttpd1 is sufficient, as only SUNWlighttpd2 will be incompatible. > Such versioning adds hassle of course. But if it is necessary, perhaps > it is. > > >> 5.3. Exported Interfaces >> > > Package names are also exported interface. > > >> NAME STABILITY NOTES >> >> /usr/bin/spawn-fcgi uncommitted executable >> /usr/sbin/lighttpd uncommitted executable >> /usr/sbin/lighttpd-angel uncommitted executable >> /usr/share/man/man1/lighttpd.1 uncommitted man page >> > > Nit: keep columns aligned, easier to read and looks better (hint: > never use tabs). > > Also, be more specific. "/usr/sbin/lighttpd" is Uncommitted, what does > that mean? Is it the physical pathname that's Uncommitted? Or the > command line options of that CLI? Or its exit code? Or the module APIs > contained in it? Something else? All of it? > > >> /usr/lighttpd/lib/mod_flv_streaming.so project private shared library >> > > Looks like everything in /usr/lighttpd/lib/mod_* is project private, > so I'd just say it that way instead of listing them all, given they're > private anyway. > > > -- Amanda Waite ISV-Engineering OSS, Sun Microsystems Tel: +44 (0)1252 420693 Mobile: +44 (0)7802 175732 AIM: pollyemic
