#include <hallo.h>
* Ross Boylan [Thu, Dec 29 2005, 07:14:28PM]:
> Package: apt-cacher
> Version: 1.1
> Severity: normal
> 
> 1. The only outright bugs here are minor: /etc/defaults/apt-cacher should
> use "default" not "defaults".  (see also point 7 for typo bug).

Ok.

> 2. For the cache_dir, explain the required subdirectory structure and
> ownership/permissions.  I was using an alternate location, and didn't
> initially realize I needed to create some subdirs.

I will add a "use the install.pl script" note. I wonder how you got that
assumption... do other HTTP proxies just throw random files without any
metadata into storage directories? ;-)

> 3. Clarify support for non-http access and source packages.  My guess
> is the former doesn't work and the latter does.  It would be nice to
> add any features that are missing.

Hm?

man apt-cacher | grep HTTP
Formatiere apt-cacher(1) neu, bitte warten...
       to  each HTTP mirror in /etc/apt/sources.list (depending on the instal‐
              Apt-cacher currently only handles HTTP requests.

I don't like adding non-HTTP URl support because it is simply
irrelevant. How many apt sources do you know that are not accessible via
HTTP?

> 4. Does the daily generation of reports or cleaning the cache depend
> on whether apt-cacher is running continuously as a daemon?  I
> suspected it did, until dpkg -L showed cron jobs.

Is that really important and why?

> 5. allow/deny hosts: Are host names permissible?  What if a host is in

What do you mean?

> both lists (a literal reading of the current description is that the
> host is denied)?  If a host is on neither list, what happens (literal
> reading: it's blocked)?  I suspect my literal reading is correct, but

That is misleading indeed and I got it wrong some times as well. There
is no way (yet) to set a Deny/Allow order and both filters are checked
when allowing access.

> because these operations are similar to apache configuration options
> (which work a bit differently), it would be worth being explicit.
> Perhaps mentioning the logic differs from Apache's would be
> worthwhile.
> 
> 6. generate_reports: how does being able to view the reports depend on
> the web server you are running?  Are they only available if apt-cacher
> is running on port 80?

Ok, should be described better... the report is stored in the log dir
and can by read by the admin, of course.

> 7.  Minor typo in the discussion of port 80 under INSTALLATION
> METHODS: I think the intent is "However, you cannot run another web
> server on the port then."  Currently "real" appears where I wrote
> "run."

I will reread it later.

> 8. The FAQ section refers to symlinks and hard links, but the help for
> the import script only mentions symlinks.  Also, the meaning of the
> options isn't really explained anywhere I could see, though they are
> not hard to guess (I hope).

Hm? Few words before: ... package files it finds in that dir and move
them around to the correct locations ...

I think move is move is move.

> 9. The FAQ answer makes it sound as if the import directory will be
> found automatically if it's under the cacher directory; I'm guessing
> that's not the case and it needs to be specified explicitly.  The

./apt-cacher-import.pl 
No import directory specified as the first argument, using
/var/cache/apt-cacher/import

Ok, it will get a more clear and correct help message.

> syntax given in the importer help implies the import location argument
> is mandatory.  Does the importer cp or mv the files it finds?  I'm

Duplicated question? Move, see above, see FAQ.

> guessing cp, in which case following the advice would double the size
> of the cache, which doesn't seem desirable.
> 
> 10. It would be good to add a "Files" section to the man page.

Why? Normally such a section displays files that can be interesting for
the user/admin, but what exactly do you expect there and why?

> 11. The stuff on installation and setup might go in README.Debian.

Which stuff? Running install.pl or explaining everything it does? This
is a Debian PACKAGE and I assume I have some freedom to automate things
instead of explaining every single bit in every doc.

> 12. Does the daemon need to be restarted to read new config settings,
> or does it look in the config file each time it handles a request?

Servers do not reread their config on every connection. I think this are
basics explained in every system manual. Do you really expect me to add
even _this_ to the manpage?

Eduard.
-- 
For any stupid thing chosen at random, you'll find at least 5 people on
the Internet who thinks it's a good idea. -- Steve Langasek in debian-devel

Reply via email to