Evidently, one of the people mentioned in the calibre blogpost helping the python3 migration is an Arch Linux contributor :)
I've been using his Arch repo shipping Calibre with Python 3 for I think over a year. My system is updating to Calibre 5 from the main repos as we speak, so I guess I'll remove the custom repo now.
Now I'm only waiting for the Kodi 19 release before Python 2 will be gone from my system forever...
Not to diminish the work of Eli, but several Arch package maintainers end up bugfixing upstream projects to keep sources unpatched. Personally done upstream contributions to several upstreams I maintain in the distribution :)
(I'm not an Arch TU or dev, but I also contribute upstream fixes for AUR packages I maintain)
I wish there was a way to say:
LAYER foo
RUN unpack_some_large_package
RUN build it
RUN install it
RUN delete stuff
LAYER bar
because the normal way of using docker makes really really large images.and the efficient use of docker is unreadable and hard to maintain:
RUN unpack_some_large_package && build it && install it && delete stuff
thing is - if you do it this way you can hack gigabytes off your image sizesThis is lots harder nowadays over vpn.
I know there's docker squash, but that is a hack on many levels.
Then there's the firewall thing
and last, I'd like to have my own private repository - where docker wont' and can't pull from other machines.
https://docs.docker.com/develop/develop-images/multistage-bu...
Simply using the "USER <uid/uname>" directory means you run as non-root user with a specified UID. Kubernetes recommends doing that as a baseline security measure. You can also drop caps from a container so even if you are root inside, you can't do a lot of things root can.
If you've ever developed for linux, you might come down on the side of the server folks. You will find that there's a web of dependencies everywhere that you will have to navigate. And the more higher-functioning what you are doing, the more likely this will become more and more complicated.
If people depend on an app, develop for something like Ubuntu 16.04 or Ubuntu 18.04. It is (more) likely that people will be able to use it without trouble for quite some time. It is very stable and it is not likely updates will affect the folks using your software. They will be able to use the software for years.
strangely, I wonder if arch linux might be the counterpoint to all this. You might just do continuous maintenance all the time instead of one-giant-upheaval-update every few years.