Debian has epochs, but it's a bad idea to use them for this purpose.

Two reasons:

1. Once you bump the epoch, you have to use it forever. 2. The deb filename often doesn't contain the epoch (we use a colon which isn't valid on many filesystems), so an epoch-revert will give the same file name as pre-epoch, which breaks your repository.

So, the current best practice is the +really+ thing.

Thanks for the info, the filename thing sounds like a problem, one aspect of the epoch system doesn't work for the purpose then.

Honestly, the Gentoo-style global blacklist (package.mask) to force a downgrade is probably a better approach for cases like this. Epochs only make sense if your upstream is insane and does not follow a consistent numbering system.

Gentoo also considers the repository (+overlays) to be the entire set of possible versions so simply removing the bad version will cause a downgrade, unlike debian and RPM systems where installing packages outside a repository is supported.

Stop the cap your honor. There is not a single filesystem that prevents you from using colons in filenames except exfat, I went ahead and checked and ext4, xfs, btrfs, zfs, and even reiserfs let you use any characters you want except \0 and /.

And I fail to see why bumping the epoch would ever be a problem. Using the epoch not a reason why its bad.

Got this on OpenSUSE: `5.6.1.revertto5.4-3.2`

If you have a system-level installed pypy, the pypy equivalent is:

  python3 -m venv -p pypy3 venv
  source venv/bin/activate
  python3 -m pip install --upgrade pip
  python3 -m pip install wheel
  pip install -r requirements.txt

Not very different...

> What is it with them which makes them feel entitled to have special "dist-packages" vs "site-packages" as is the default? This drives me nuts, when I have a bunch of native packages I want to bundle in our in-house python deployment. CentOS and Ubuntu are vanilla, and only Debian (mind-boggingly) deviates from the well-trodden path.

Hi, I'm one of the people that look after this bit of Debian (and it's exactly the same in Ubuntu, FWIW).

It's like that to solve a problem (of course, everything has a reason). The idea is that Debian provides a Python that's deeply integrated into Debian packages. But if you want to build your own Python from source, you can. What you build will use site-packages, so it won't have any overlap with Debian's Python.

Unfortunately, while this approach was designed to be something all package-managed distributions could do, nobody else has adopted it, and consequently the code to make it work has never been pushed upstream. So, it's left as a Debian/Ubuntu oddity that confuses people. Sorry about that.

My recommendations are: 1. If you want more control over your Python than you get from Debian's package-managed python, build your own from source (or use a docker image that does that). 2. Deploy your apps with virtualenvs or system-level containers per app.

> firmware updates for BIOS among other things

There's a growing distro-agnostic solution here, LVFS fwupd https://fwupd.org/

Looks like the problem was somewhere between noris.net and hetzner - so it was unaccessable from some bits of the net.