On 09-mar-09, at 07:07, Gunnar Wolf wrote:

> Or, of course, if any of the ones I currently package as a plugin
> should be distributed as part of the core. IMHO, the only reason to
> split off a plugin to a package of its own is to reduce the list of
> dependencies for a minimal cherokee base packaging - So, i.e.,

I think that's the best option. I'd personally distribute all the  
modules with the main Cherokee package unless it depends on a third  
party library, in which case I'd create a new package.

> libcherokee-mod-streaming is well justified because of the libav* -
> But should I push for the same, say, for gzip?

As far as I remember, libz is part of LSB and the basic Debian system,  
isn't it? If so, I'd pack this module in the main package.

> For geoip?

Depends on libgeoip, so I'd make a new package.

> Does
> libplugin_phpcgi.so really depend on PHP, or just expects it to be
> there?

Ummm.. not any longer. I don't think anybody is using it nowadays. In  
fact, the time is about to come to remove it from the upstream source  
tree.

> What about PAM?

No dependencies on non-basic libs. Thus, I'd put it straight in to the  
main package.

> What's the deal with fastcgi/fcgi? I know
> Apache went from one to the other, but because of some dirtiness
> issues I would love not to have in Cherokee :)

I'd also leave FastCGI and SCGI in the main package. Neither of them  
depend on any external lib (and they are quite small).

> Anyway... Time to go for today. Too many questions asked... This will
> be done soon, don't desperate :)


Thanks a bunch Gunnar! :-)

--
Octality
http://www.octality.com/

_______________________________________________
Cherokee mailing list
[email protected]
http://lists.octality.com/listinfo/cherokee

Reply via email to