Re: How granular should a package{,set} be?
Well, i think the basic principle is
"split everything that people might want to install independantly or
that can be upgraded independantly"
So i think it's a good idea to enable people to install most parts of
your suite, but leave the httpd away (if they want to use some other
httpd etc.)
I don't think the -docs package should Recommend any non-docs package.
Many people will install your kit on one machine, the docs on another.
But p.e. it makes sense that libgnome-doc recommends libgtk-doc
FYI: The first thing that came into my mind, when i read about your
package, was "oh, another proxy" and "is that really really secure".
It scares me a bit that you include even an httpd server (which have to
do a lot of security checks)...
Why not use existing, audited software?
There are small httpd servers, what's wrong with them?
Same for the httpd proxy: If i look at squid, a proper caching httpd
proxy with good performance is a LOT of work, why not use squid?
And if squid is lacking some features etc. create a spin-off project
from squid with a few "squid-veterans" which have learned from their
mistakes with squid. Same for all other parts of your software.
Just the 2¢ that came into my mind, i haven't looked at your code at
all, these are just prejudices to any new software having more parts
than developers.
Greetings,
Erich
P.S.
There is no pseudo package httpd or web-server provided by apache?
We've got quite a few httpd's (roxen, boa, dhttpd wn) so maybe two
web-server and web-server-cgi pseudo packages would be a good idea?
Reply to: