If you know which package or packages ($PKG) are involved you can use the following to see which files they provide:

dpkg -L $PKG

You might also try to find it with:

find /opt /usr /var -name appcompat

Did you clean out all the old files before running that test? Because that file is a single index and your output shows processing of 7 index files. If you want to pursue that further you will need to make sure to output the problem filenames as well.

Perhaps you should clean out all the old stuff and set up the sources according to my instruction above. Don't include empty repositories. You may consider it all a bug that apt-mirror cannot deal with empty repositories. I don't.

EDIT:  I see that the experimental repo Source index doesn't have a "Files:" tag. If that is the reason apt-mirror takes issue with it, I agree that apt-mirror seems to  have a bug (being unable to deal with that repo format).  You may need exclude that repo (as well) from your mirroring.

pkgmaster.devuan.org/devuan experimental is the only repo to mirror.

pkgmaster.devuan.org/devuan main contains the special devuan packages, i.e. forked and extras and those should be accessed via
pkgmaster.devuan.org/merged main rather, or
deb.devuan.org/merged main would really be better.

pkgmaster.devuan.org/devuan contrib is empty, and
pkgmaster.devuan.org/devuan non-free-firmware is empty.

It looks like apt-mirror doesn't like empty repositories. I wouldn't consider it a bug worth fixing, but you may of course lodge a bug report to debian about that if you think differently.

"the config file"... which ? Could you perhaps show that config file?
which command gives that output?

EDIT: ... and which system version do you have?

EDIT 2: ... as a start point: the error reported is a "local software error" rather than badness in the data. All Source indexes have a "Files" tag, so the question would be why the local software is buggy upon seeing that tag. Therefore it's important to know which system version you have and which version the software that shows this bug has.

The point of running certbot more often is simply because a renewal attempt may fail for many possible technical reasons. If you set it up to only run once a month, any such failure would lead to needing operator hands-on.

Therefore all such renewal processes have "busy wait" design that begins with the test if it's yet time for a renewal and return as failure if not. If it is time for renewal, an actual renewal attempt is made, and that may succeed or fail for external reasons. If it fails, then the next run will again discover that it (still) is time for renewal and make another attempt. Etc. When the renewal succeeds,  the local state changes so the next run will again opt out early because renewal is not (yet) needed.

Now, both that check for systemd and that randomized delay are unnecessary components. Your system does not need to check and re-check for the presence of systemd, since that is a constant.  And you can choose a random but fixed start time  for your certbot runs, which will be an equivalent collegial measure for avoiding clogging the remote end when actual renewal requests are made (there is no statistically motivated reason to pick a new random start time every time).

you're welcome.

@Altoid: spelling mistake is one thing; honouring us by treating us as equal is another

I'm  not sure where the security angle is, but it all sounds like it could be a fun project. Of course there are few other filesystem points that need to be writeable for a working system. Most if not all could probably be set up tempfs.

Wonderful. Let's wait together. When some packages turn up in Debian offering all or some of those good things you talk about, then they automatically turn up in Devuan. Unless they depend on systemd. If they do, they end up on the banned packages list. Unless someone takes on the effort of forking and untangling the systemd dependencies.

Talk is cheap.

There are numerous of ways to run programs, including to run programs that keeps other programs running. If a person wants their machine to do that then they would set it up to do so. Or are we working on a premise that end users are stupid, or that end users should be controlled (by owner-administrator-vendor)?

Looks to me like your system is all good and that you have run into a flaw in debian's package provisioning; namely that they happen to include a host that is currently unresponsive.

Debian packages are accessed (by your host) via the domain deb.debian.org which afaik is resolved by "fastly" into one (or possibly a few) actual host IP, and it happens that it transiently offers "bad" IP.

If you want your resolution of deb.debian.org go to a specific host of your choice, then you may set up that resolution in your /etc/hosts file.

Sometimes this kind of thing happens if your local meta files are outdated, in which case you will have to run apt-get update to freshen them.