ownCloud and distribution packaging

There seemed to have been a similar situation in Fedora earlier this year with OwnCloud. The maintainer I believe ran into the same issues and came to the conclusion that dropping it was better case for their own wellbeing. As you said in the end, these sorts of packaging wars come and go. They were very big in the early 1990's and then when people had to maintain production versus student projects the need for various packaging standards became more needed. I expect that Docker and similar tools will end up with the same types of packaging as continual deployment reaches its limits in various environments.

I'm amazed at how many projects still try to provide poor quality packages for various distributions. Many projects would probably be better off just providing source and docker images. Whoever is interested in packaging software for distributions should be encouraged to work with distributions.

I'm a Systems Engineer. I build solutions. And not only solutions that "run", but solutions that are maintainable throughout the whole life-cycle.

And one of the keystones to do that properly, is package management. The last few years we've seen constant disputes between distributions and things like developer-only languages like ruby, weird packaging-solutions as docker, and now ownCloud. And it's always the same: The developers of these things usually focus on developers and small-time end-users. And very much ignore system administration.

Yes you can have the newest ruby-on-rails, but then puppet won't work at the same time, on the same machine. Yes you can install these containers on some machine, but they won't be updated. Yes you can have the latest ownCloud, but then it pulls in duplicate libraries that won't get security upgrades. You can do this if you run one machine, you can't do this if you run dozens of machines.

And while they're arguing they need the latest and newest framework from git, they're packaging old SSL libraries at the same time. Because if you're working like that, you don't have any package management yourself. You don't really have the slightest idea what versions of what you really use, and this will be reflected by what you push out.

And this is simply not how you build sustainable systems. If you have a lot of machines, you need to be sure that you're running the same things, in the same versions everywhere; you can't just go "pip install" somewhere, and two weeks later somewhere else, where it will install a different version. And then wonder why it works on one machine but not on the other. And you can't just install some tarballs, and keep track of dozens of these things all around your systems to keep the up-to-date. You need to be able to rely on the package management, and on timely security upgrades; and that these upgrades really upgrade every instance of the vulnerable library.

So yeah, in fighting against distributions package management, you're actually fighting against system engineers and system administrators. Against the people that most likely need to install your software. Stupid.

>To his eye, the future of packaging is in projects like Docker, while "Debian and other distributions are going to be that thing you run docker on, little more."

We're reading how Ian Murdock put together a system to manage interdependencies on GNU/Linux systems as part of reflecting on losing Ian Murdock while, next to it, there's this. It has the familiar pattern of a business saying 'not invented here -- use our tarballs' in place of proper package management. This claim that serious production deployments will use download-and-deploy containers deserves contempt -- almost everything has a small amount of custom configuration and kludges, and everything done right has verification from the ground up and systems which ensure continued effective interoperation. Worse, when we benefit from distribution communities working hard to have packaged software play nicely together, this is Jos Poortvliet and OwnCloud (careful to not apply my own mental habit of s/cloud/clown here) wanting to drop that work on their users.

K3n.

One of the problems, which I suspect OwnCloud is facing is mutually conflicting interdependent software, especially on 3rd-party distributions. If there is a dependency on package X being at version xii, while there is another dependency on package Y, which will only run with package X at version xi, there is a conflict. In one package, it's easier to manage that conflict, either by fixing package Y to work with package X version xii, or working around the direct dependency of package X version xii, possibly by forking project X and only backporting one fix from version xii to the fork. Solving this problem with a distribution is harder, as the original package may have nothing to do with package Y, leaving the distributor with little knowledge of the original package or package Y to come up with a reasonable solution. By the same token, if the distribution changes package Y to backport a fix, they are unlikely to ensure that this change doesn't affect the original package. Since each upstream is independent, they work at their own pace, and it's difficult to find mutually interworking versions of all packages, which is why making distributions is so hard. The major advantage of distributions is incorporation of security fixes on a timely basis, minimizing storage and memory requirements by using common versions.

I'm not sure how to best addresses these issues, but one approach would enable more packages to support multiple versions, and for packages to declare compatible package versions of its dependencies. This would require each package to have it's own set of links to the packages it needs, and starting another package from the first one would be complicated. But neither the current package model, nor the integrated application model seems to be optimal.

> Sorry, this is a flame, but there is a reason for Docker's popularity: the distributions have failed to keep up.

Distros certainly are struggling to keep up... with how rapidly standards of software engineering are plummeting.

Even Windows now discourages this attitude of “we own a chunk of your computer if you use our software”. ownCloud apparently didn't get the memo.

Their poor package quality and inability to sanely upgrade from one point release to the next was one of the reasons I ended up giving up on OC entirely in the 7.x days.

I'm talking about basic failures like having to manually disable maintenance mode and more often than not, be forced to manually re-enable the PIM plugins which, for me, were the entire point of using OC.

As a final insult, their CalDav and CardDAV export features turned out to be a little buggy too, but in their defence those specs have a lot of ambiguity.

I just published a blog post on ownCloud.org on <a href="https://owncloud.org/blog/making-owncloud-upgrades-more-r...">our work on improving the upgrade process</a>. It might address some of the comments and concerns, too.

Seriously? Firstly, with all the cool people shovelling their stuff onto GitHub, when can we expect the accompanying BitKeeper moment? The editor obviously didn't feel confident enough to pencil that in for this year in his predictions.

And from my experiences with another fairly visible project, the Open Build System just seems to be another way that the SuSE brigade gets to tick all the distribution boxes by putting out poor quality packages for all the other distributions. My impression is that OBS is advocated by people who don't fully appreciate all the necessary aspects of distribution packaging, especially when those advocates insist on it being used as the basis of proper distribution packages.

It is certainly the case that distribution packagers have got things wrong in the past. For example, a few years ago now, some developers of a certain Web solution told me that there had been some odd practices in Debian to migrate content between versions of their software when there is actually a standard migration script for that purpose that the package maintainers had either overlooked or discounted needlessly. That isn't an encouraging sign when you are relying on the distribution to do the right thing, but maybe this was either misreported or I misunderstood.

But there is tremendous benefit in having distribution packages for things that you need to run but don't have the time to become immersed in, where it would be beneficial to rely on others' expertise. I've deployed MediaWiki on Red Hat Enterprise Linux before - not my choice, but mandated by my boss at the time - but there's just no way I'd want to familiarise myself personally with every aspect of PHP deployment just to be able to do this, especially alongside having to do real work.

People just want things to work, rather than having to become experts in everything, particularly when everything involves every half-baked "off onto the Internet to download stuff" language- and application-specific packaging system known to man, woman and animal. And adding random package sources with "up today, down tomorrow" characteristics and vague repository key availability, just because that's where some company serves "the fresh stuff", isn't the answer, either.

To me, a distro is mainly about trust. I can't be a specialist on the many packages (currently 1680) installed on my box. Of those, I know perhaps a dozen, I compile perhaps half a dozen.

I really appreciate the fact that there's some specialist looking at the rest of those and putting lots of work towards making sure that they Just Work (in the context of the distro). When I feel specially about one package, I'll get that from upstream and do whatever magic it needs to get it running -- but I like to choose myself which package is important to me and which not.

So thanks, distros! (and very especially: thanks Debian!)

Another thing: this discussion has made my decision about ownCloud: I'll stay clear of it.