If you would spell it correctly it might work ?

Same as what? In what way is this related to failure of starting OpenSSH?

It's bad form to wake an old thread with just an useless sentence and some copy-paste.

Start your own issue, and explain what you did, what you expected should happen and what happened.

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.