The size of Alpine and its package manager are brilliant. What gets me, and my team, is the support policy for “older” packages.
For a while we would pin library versions (e.g. libvips) only to have the pin break the build because the package was no longer provided. That’s only a few months later, not years. It seriously impacts the repeatability of Docker builds.
Now we don’t pin to the same extent and lack some confidence, but at least it doesn’t break the build.
This is an issue you'll have with any distribution though. That's where you start having your own repository from which your docker builds will pull packages
> This is an issue you'll have with any distribution though
This is (almost self-evidently) true in theory, but not really in practice. It's about finding the sweet spot between LTS and maintainability. As the commenter said:
> only a few months later, not years
The lifecycle is usually longer with other distros.
This got me thinking. If one want to start an open source project which requires a lot of manpower like this, where to get the funding to start the project? Starting without funding means you'll have to gather a team of unpaid contributors, and for big projects like Alpine, you'll probably need to gather a lot of them. How these big open source projects got bootstrapped?
Alpine has started doing point releases to help address some of these pains. However, as with most things it is usually best to have a testing strategy in place before doing upgrades.
For a while we would pin library versions (e.g. libvips) only to have the pin break the build because the package was no longer provided. That’s only a few months later, not years. It seriously impacts the repeatability of Docker builds.
Now we don’t pin to the same extent and lack some confidence, but at least it doesn’t break the build.