The problem about "consistent packaging"
(Warning: long post ahead!)
I was reading Mark Shuttleworth’s comment about Consistent Packaging, and although I’ve not yet read all the comments on his post, I have my own concerns that I wish to express here (so I won’t pollute his mailbox with redundant comments, if that’s the case).
As being one big Smart Package Manager contributor, I think I’m eligible to an opinion. We’ve already faced many situations where users suggested to use Smart as the main package manager on their distributions, and we have seen many kinds of reactions to those requests. Many of them generate discussions that tend to fall on the packaging standardization matter, so I think I can say something about Mark’s post.
Before proceeding, remember it’s just my humble opinion. It’s no way related to Smart, it’s development or it’s acceptance. Please, I’m trying to be neutral here.
So the problems I see here are:
1 – Ego
Once I saw a presentation from my friend Osvaldo Santana about how to manage a FOSS project where he said something that would sound similar to this: FOSS developers have a huge ego (…) if you put two of them on a big stadium to defend their ideas, their ego would inflate so much it won’t have enough space for the audience. (Ok, not a direct quote, just what I felt he wishes to say)
And what that means? The battle between RPM and DEB is a long running war, which may still exist for centuries to come. Yes, I know Mark didn’t mention “lets use this” or “let’s use that”, but you know someway, somehow, someone would fall in this topic. And see that I’m not even including tarballs, portage, klik or any other exotic packaging system on this matter!
Even if there’s a magic proposal for an hybrid or a completely new format, people with strong preferences would still battle for including the features they think are better on their preferred format than the other.
Do I have a solution? Obviously not! I’m completely out of this discussion, and I intend to stay like this (at least for now). My feeling is that the people from LSB have what it needs to find a nice solution, even if this solution won’t get widely adopted, which brings us to the next problem.
2 – NDH (not developed here)
I’ve heard that so many times I simply stop counting. And I’m not talking specifically about Smart. This argument is used with many other things, specially system tools, file location standards (let’s not forget FHS either), service handling, system initialization methods/scripts, etc (ok, let’s not divert from the topic).
What I mean is that, along with the previously mentioned ego, the fact that something is not internally developed is enough motivation to simply drop some nice ideas. I’m not saying that all distros act like that, or that the distro developers are self-centric bastards, but you’ve got to admit that if NDH didn’t exist, we wouldn’t have so many Linux distros around. Agreed?
3 – Unleveled development
The NDH issue creates the problem of the unleveled development. Considering each distro team wants/needs/decides to develop a new/modified method to achieve their users/clients/partners goals, every and each single distro is self-centered on a personalized development cycle, with their own goals, needs and methods.
If we completely ignore the previously mentioned problems we could simply expect that all the distros work in sync like on the automobile industry. Even with different products, market shares and niches, most of them work with a nice seasonality: they tend to release the new models almost on the same period of the year, very close to each other.
That, IMHO, would be another great problem to be solved before having a consistent packaging system. The distros would need to work in sync so they always have the same package capabilities, store the files on the same places, have a consistent pre/post scripting system and, who knows, even the same package manager features.
4 – Conclusion
So, my point is: I agree with Mark, to a certain point. We sure should have a very consistent packaging system, along with a strong LSB and FHS and anything needed to make these things work together. We’ve already seen many proposals on that, like United Linux, LCC and even DCC (supported by Mark, I guess).
Despite of all best efforts given on those projects, we’re still here to see any consistent solution that would come from any of them. They all failed most because of the problems I mentioned since I started writing this post.
Hey! Let’s not forget the fact that if we really manage to solve all these problems, the distro maintainers would have enough time to focus on what really matters: innovation, stability, security, and the best user experience.
Bottom lime, let’s drop the cheap talk, put our egos aside and start work on something that would bring true benefits to the Linux world.