- cross-posted to:
- linux@lemmy.ml
- cross-posted to:
- linux@lemmy.ml
Heads up if you’re using Alpine images to host your services or run build pipelines. Alpine’s packages are going to be less current unless some others maintainers are found to pick up the slack.
You must log in or register to comment.
So she did half of the work
Yes, she literally did more commits than 347 other people. (every other maintainer this year)
I always assumed that the authors of a project also provided the packages. Apparently not, but I cannot imagine why…
One of the reasons for the #DevOps movement is developers see building and packaging as #notmyjob.
The task would historically fall on the most junior member of the team, who would make a pigs ear out of it due to complete lack of experience.
This is compounded by the issue that most C/C++ build systems don’t really include dependency management.
Linux distributions have all tried to work out those dependency trees but they came up with slightly different solutions. This is why there are a few “root” distributions everything branches from.
That means developers have to learn about a few root distributions to design a deb/rpm/aur package systems to base their release around.
That is a considerable amount of learning in a subject most aren’t interested in.
The real question is why don’t package maintainers upstream a packaging solution?
That is a good question.
I suspect the answer can be found by looking at the Linux ecosystem.
20,000 opinions and 200 of them are willing to build their own distribution.
Don’t get me wrong, I love Unix and Linux, but there’s a metric ton of toxic personalities involved.
I’m sure a lot of it can be attributed to people having to be somewhere on the spectrum to even spend time contributing to free software on their own spare time, but a lot of people who build their own stuff tend to get quite attached to it as well.
Maybe all this friction actually is a good thing and it causes progress, but on the other hand I can’t help to think about where we could have been if everyone was pulling in the same direction.
@stevecrox your argument would have better weight if you didn’t imply that “toxic personalities” were due to being “on the spectrum.” There’s no more assholes in FOSS than any other group. They’re just always the loudest.
Not saying they’re assholes, but self-centered maybe.
@ergoplato I didn’t suggest that.
Personally I don’t think its ego. I think you have two issues.
The first is people go through stages learning DevOps. Stage 1 has people deploy a CI because its cool, they build a few basic pipelines and then 90% of people get bored. The 2nd stage is people start extending those pipelines, it results in really complex pipelines requiring lots of unique changes based on the opinion of the writer. You move to the 3rd stage when your asked to recreate/extend for a new project and realise how specific your solutions are.
Learning how to make minor tweaks and hook in a few key points to get what you want takes years. Without that most packagers will want to make big changes upstream which won’t go down well.
The second issue, I have met quite a few developers who become highly stressed when the build system is doing something they haven’t needed to do or understand.
A really simple example I have a Jenkins function which I tend to slip into release pipelines, it captures the release version and creates a version in Jira.
I normally deploy it first as a test before a few other functions to automate various service management requirements.
Its surprising how many devs will suddenly decide every problem (test failed, code failed review, sharepoint breaks, bad os update, etc…) is due to that function.
For me this little function is a test, if the team don’t care I will work to integrate various bits. If they freak out, I’ll revert decide if it is worth walking them through the process or walk away.
There are a lot of distros to maintain packages for, hence a lot of work to be done. Developing a program is difficult enough, but add on the task of maintaining packages and the work goes up by an order of magnitude. That’s why solutions like Snap and Flatpak were created, so packaging could be distro-agnostic.
For every distro there will be a group of package maintainers that handle this. The original authors will usually provide it in their own repo or a container build. But they (probably) won’t have permission to host that on the official repo of every distro cause that’s dangerous. You’d have all sorts of stability issues and dependency problems.
