Re: How granular should a package{,set} be?
On Fri, 12 Oct 2001, Erich Schubert wrote:
> Well, i think the basic principle is
> "split everything that people might want to install independantly or
> that can be upgraded independantly"
The "upgraded independantly" is a good point. As an
in-development package, I wouldn't at the point be
entirely happy with people running older versions if
they wanted stability.
> 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.)
Perhaps I should package it as fk, fk-tools, fk-httpd then?
Doco could go into the first package. I do see the point of
not having a large number of packages each of which contains
only a single binary.
> 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
Good point.
[ Below here is off-topic. Feel free to reply off-list ]
> 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".
"another proxy"? Please point me to a decent, non-abandoned,
Free software proxy firewall kit. I know only of Zorp, and
they have very different design objectives to me. Both fwtk
and delegate have (IMHO) serious code-quality issues, and the
former is non-free.
As to the security aspects, I'd much rather you didn't make
such implications without at least having a look for yourself.
One of my design goals is that it be possible to audit the kit
merely by reading the source through once. The code isn't
perfect (what code is?) but I do believe that I have had better
than reasonable success towards that target.
> Why not use existing, audited software?
Please point me towards an existing, audited, maintained,
free software ftp gateway. Or a nice, unified, access-
control framework more suited to gateways than tcpd.
> There are small httpd servers, what's wrong with them?
There is probably nothing wrong with them. They just do
not share my design goals.
> 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?
Because I don't want a caching http proxy with good
performance (though the latter wiould be nice). I want
an Obviously Safe To Run http proxy which supports the
access-control mechanism that I have designed.
> 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?
I'd favour that. Also possibly a web-server-ssl.
Matthew.
Reply to: