Tianon Gravi

> @tianon any thoughts? I mean, you know my thoughts on this script... :sweat_smile: (I would've deprecated it years ago - I think it does more harm than good. :innocent:)...

This seems kind of similar to https://github.com/cesanta/docker_auth/issues/117, and thus could probably be helped by https://github.com/cesanta/docker_auth/pull/139, right?

I think the contents of https://github.com/docker-library/docs/pull/1215 are probably relevant here -- I imagine given a volume with appropriate permissions for the user the container gets run as, this will mostly...

Does this really make much difference in a network namespace sitting on a private (internal) network with a non-public IP? I'm generally a big fan of https://github.com/moby/moby/issues/8460#issuecomment-312459310, wherein one uses...

> Note: the commit messages produced by @docker-library-bot might be garbage. I'd take that one step further -- if this merges as-is, I will be disabling the @docker-library-bot automation for...

As long as it's still flexible, I'm not opposed! By flexible, I mean allowing users to supply their own `ssmtp.conf` which doesn't get overwritten if they don't supply any environment...

You definitely shouldn't rely on running `perl`/`cpanm` via `update.sh` if you want @docker-library-bot to be running it. It's reasonable to rely on `curl`/`wget`/`jq`, but `perl` or `cpanm` is too much....

Conceptually I think this is OK, but I have a couple practical concerns with this. The first is that there are already quite a few tags on https://hub.docker.com/_/perl, and this...

Both of those options sound really reasonable to me -- do y'all already have control of the `perl` namespace on Docker Hub? (that seems like a great place for these...

I think it's taken, but there don't appear to be any repos, so I think it's just a squatter and Docker support might either take pity on you, get in...