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