OK, first of all, I apologize for the tone of my email. I was tired and cranky when I wrote it, but that's no excuse.
Eduard Bloch wrote: > Hallo, > * Trent W. Buck [Tue, Oct 15 2019, 01:41:53PM]: > > Package: apt-cacher-ng > > Version: 3.2-2 > > Severity: minor > > > > Right now apt-cacher-ng ships with TWO sets of default values: > > the ones hard-coded into the binary, and > > the ones in the default config file. > > Wrong. Because there is no "default config file". I am referring to the difference between... https://sources.debian.org/src/apt-cacher-ng/3.2-2/source/acfg_defaults.cc/#L19 string cachedir("/var/tmp"), logdir("/var/tmp"), fifopath, pidfile, reportpage, ...and https://sources.debian.org/src/apt-cacher-ng/3.2-2/conf/acng.conf.in/#L22 CacheDir: /var/cache/apt-cacher-ng LogDir: /var/log/apt-cacher-ng To me, these look like inconsistent defaults, and the obvious way to make them consistent is this: diff --git i/source/acfg_defaults.cc w/source/acfg_defaults.cc index 4a582c0..6e3311e 100644 --- i/source/acfg_defaults.cc +++ w/source/acfg_defaults.cc @@ -19 +19 @@ namespace cfg -string cachedir("/var/tmp"), logdir("/var/tmp"), fifopath, pidfile, reportpage, +string cachedir("/var/cache/apt-cacher-ng"), logdir("/var/log/apt-cacher-ng"), fifopath, pidfile, reportpage, diff --git i/conf/acng.conf.in w/conf/acng.conf.in index cedbaf5..fbf5772 100644 --- i/conf/acng.conf.in +++ w/conf/acng.conf.in @@ -22 +22 @@ -CacheDir: /var/cache/apt-cacher-ng +#CacheDir: /var/cache/apt-cacher-ng @@ -26 +26 @@ CacheDir: /var/cache/apt-cacher-ng -LogDir: /var/log/apt-cacher-ng +#LogDir: /var/log/apt-cacher-ng Is there a good reason for cachedir and logdir to both be just /var/tmp there? I can't work out why you would ever want to cache and log directly into /var/tmp (not even a subdir), which is why I called it as "dumb". I apologize for doing so. You're right, that's entirely subjective. Probably there is a good reason, and *I'm* too dumb to see it! Also, I didn't actually read the source code during my original bug report; sorry. > > # mkdir fnord # empty directory, i.e. compiled-in config > [...] > > # /usr/lib/apt-cacher-ng/acngtool printvar -c fnord ExThreshold > > 20 > > WTF is "fnord" and what do you want to demonstrate? fnord is an empty directory, to show experimentally what behaviour apt-cacher-ng (or at least acngtool printvar) has when there is no runtime configuration at all. > > ...but AFAICT to achieve that I have to DELETE "Remap"-gentoo &c from > > acng.conf. > > I don't think I can do that from a dropin, e.g. this doesn't work: > > > > # cat /etc/apt-cacher-ng/zzz_cyber.conf > > Remap-gentoo: > > Why don't you start with that, instead of calling things "dumb"? The response I expected was along the lines of "oops, the hard-coded /var/tmp is leftover code from years ago, I didn't realize it was still there. Fixed." If that was so, the "why I want this" context is irrelevant and distracting. > Sound like all you want is "picking all bits from the config folder > except for the ones I don't like". Is this your requirement? My high-level requirement goal is the one I (tried to) give - to have apt-cacher-ng only serve Debian content (deb.debian.org and security-cdn.debian.org). *One* way to achieve that might be 1. leave acng.conf untouched 2. in local.conf, set ForceManaged: 1 3. in local.conf, disable Remap-sfnet &c that appear in acng.conf. I couldn't work out how to do #3. At that point the normal workaround is "just delete the Remap lines from acng.conf", but naïve code like "sed -i /^Remap/d acng.conf" is error-prone, which is why augeas (http://augeas.net/) exists: Augeas goals: • Manipulate configuration files safely, safer than the ad-hoc techniques generally used with grep, sed, awk and similar mechanisms in scripting languages. Then the "just delete the Remap lines" would look something like #!/usr/bin/augtool -f rm /files/etc/apt-cacher-ng/acng.conf/*[starts-with(key, "Remap-")] Unfortunately that also runs into a snag because acng.conf's file format isn't exactly like anything else (e.g. not JSON), so before I can use augeas, I have to write a parser --- what augeas calls a "lens" --- for the acng.conf file format. Which is pretty horrible because augeas lenses are in their own non-standard language that looks vaguely like SML or ocaml. An alternate workaround is simply to delete *all* of acng.conf. If I do that, CacheDir becomes /var/tmp due to acfg_defaults.cc, so I have to copy-paste the CacheDir line into my "completely replace acng.conf" config file. PS: another method is "just edit the config file by hand". The only problem with that is rebuilding the server isn't completely automatic. PPS: actually, acng.conf's format might be perfectly valid standard deb822 format. My initial attempts to treat it as deb822 failed, but that could just be bugs in augeas. I'll have to go re-read the deb822 specification. >> So I have to edit acng.conf itself. augtool doesn't have a lens >> for acng.conf, because it's a weird "unique snowflake" format. > > The WHAT? Am I supposed to guess what you mean now? This is a reference to a soliloquy in the book/movie "Fight Club", see https://en.wikipedia.org/wiki/Snowflake_(slang) In this context, it was meant to be a shorthand for Why isn't the config file in a standard format (e.g. JSON or XML or even deb822)? My configuration management and validation and syntax highlighting tools know how to work with standard formats. They don't know how to work with a format that's only used in apt-cacher-ng. It also means apt-cacher-ng has to maintain its own parsing code instead of a standard library (e.g. libjson-xs-perl or libexpat or python-deb822). I thought this idiom was widely understood in sysadmin circles, but I guess it's specific to the groups I hang out with. Sorry for the confusion.
