While working on the RaspberryPi setup, which I decided is going to use wview as the main component, I’ve started wondering once again why some upstream projects really feel like they don’t want to be friendly with distributions and other developers at all.
It’s not like they are hostile, just really unfriendly.
First of all, wview comes with its own utility library (more on that in a different post); both projects don’t have a public repository, they are developed behind closed doors, but you can send patches. This is bothersome but not a big deal. But when you send patches, and it goes weeks without answers, and without any idea if the patch was merged, well, things get bothersome.
But this is not the only project lately that seems to have this kind of problems. Google’s PageSpeed has binary package snapshots for Debian and CentOS but they have no related source release. Indeed, if you want the sources, you’re supposed to fetch them from the repository using Google’s own repo tools, rather than any standard SCM software. While I was interested in trying the module, the idea of having to deal with repo tools once again didn’t enthusiasm me, so I stopped looking into it at all.
This, to me, looks like a common problem: who cares about the policies that distribution had for years, make it agile, make it easy, and stop doing releases, git is good for everybody and so is bzr, hg and monotone! And then the poor distribution packages need to suffer.
Who cares about pkg-config and the fact that it supports cross-compilation out of the box? Just rely on custom -config scripts!
Why waste time making things work once installed at system level? They work good enough out of a repository!
Sigh.
Can’t disagree here. Everyone release straight from git. Security incidents are raining. Reliability is dropping. But thats ok. Shipping matters more!Don’t forget, if you bug fix, don’t write something too clear in the commit. Don’t say if its security related or not. Don’t tell anyone if it’s important. Well, unless it had any kind of publicity of course.Likewise, taking the time to understand compatibility, or stuff, like, how dare you, pkg-config? That’s at least 20min of reading. Wait too long.Likewise, releasing binary packages, generally compiled for platforms with specific libraries, is apparently the norm.Can’t wait for the projects throwing out ./configure.py that does config and build in python, with zero deps tracking, zero compat, and mostly fails everywhere but the latest ubuntu (obviously).
@zang .. I already found that kind of software already some time ago (sorry , forgot the name of it because I wiped it off my disk after recognizing that and looked for some other solution)I think in future we have to face these type of packages more often as Linux becomes more popular. So Linux also comes into the focus of big companies and their interests. Not all of these interests are … lets say .. “open-source-compatible”. One of my worstcase-scenarios I can imagine is that the linux-world as a whole will change dramatically. For example many core-linux components may contain closed-source parts. I hope that won’t happen ever.Maybe Ubuntu is the first sign on the horizon pointing into that direction.
Hey, I think you probably shouldn’t be TOO negative here. I can really understand that not everybody wants to learn about all kind of portability foo between different POSIX system, and about how to use e.g. autotools /properly/ (not as easy as you could think) to make your software “packageable”. I’m kind of struggling every time I use autotools (still like the flexibility, though) — and I only test whether I can build a .deb package; as a Debian user, this is most important to me ;)[little rant here: why do autotools and dpkg have different ideas about the naming of a distributed source tarball? autotools: <name>-<ver>.<ext>, dpkg: <name>_<ver>(.orig)?.<ext> — forget about the .orig for native packages, they only differ in minus vs. underscore between name and version. Well, I blame dpkg here, the autotools naming seems to be much more common]Oh and, I don’t think there’s anything wrong with “agile” development methods. Even in opensource, it doesn’t have to mean “drop releases completely, cause every commit is a release”. No — all SCM tools I’m aware of make it relatively easy to manage one release branch in parallel to development. Btw, I still stick with svn, cause I’m too lazy to learn using anything new in depth.
Oh wow, the blog ate my non-terminals in the naming shemes, I wrote them using angle brackets, so probably html-tag stripping done cheaply. then again: autotools: [name]-[ver].[ext], dpkg: [name]_[ver](.orig)?.[ext]