[Pkg-owncloud-maintainers] Bug#816376: Bug#816376: Unfit upstream
martin at lichtvoll.de
Wed Mar 9 22:51:16 UTC 2016
On Mittwoch, 9. März 2016 22:30:13 CET Jos Poortvliet wrote:
> On woensdag 9 maart 2016 19:21:31 CET MJ Ray wrote:
> > Jos Poortvliet wrote:
> > > The situation is rather sad and frustrating as users who decided to
> > > trust
> > > the Debian developers and took their packages over ownCloud's provided
> > > packages are now stuck on a version which can't trivially be upgraded to
> > > either our upstream version or anything else. We would love to find a
> > > solution for them - as I've said many times, our main concern is the end
> > > users, rather than politics, rules or anything else.
> > One of the debian project's top priorities is its users and it has
> > rather more track record of providing solid software for them for the
> > long term which is WHY the various rules, policies and guidelines were
> > defined. They weren't just adopted as self-flagellation by masochists.
> > There seems to be a complete and total lack of appreciation for that
> > upstream in this instance.
> Well, it's true that I'm rather skeptical of some of these rules, yes. We
> (myself and many others at ownCloud) aren't exactly new to the world of
> distributions - my previous job was at SUSE, the same goes for our CEO and
> half the management team and many others.
> I've said it would be healthy for distributions (in general, I haven't aimed
> at Debian or any other specific distro in this regard) to re-think these
> rules as many of them were developed for applications of a rather different
> kind (C/ C++ console or desktop tools, mostly). Now I know many of the
> modern languages have been doing stupid stuff like re-creating packaging
> tools (eg ruby, php and others) and that creates all kinds of annoying
Beware, this may be somewhat of a flame, but honestly right now I am quite a
bit fed up with "either you support the new web app developers way of doing
things or you will become obsolete except for running containers"
I use Debian on my server cause of those rules. They provide me some sanity
for maintaining it.
With Debian I have one upgrade every about three years. And the rules in
Debian make sure that upgrades are working very smoothly and most rough things
are documented in the releasenotes. I´d even go as far as that Debian is one
of the distributions with the best track record on upgrading. And that since
more than 10 years even at times where one would just re-install a SUSE or
RedHat distribution with every major upgrade, cause upgrades just didn´t work
out at all, neither were they supported.
Now, I do think after what I learned here that the upgrading of Owncloud is a
complete mess compared to the standards I know from Debian. It just does not
compare in any sensible way to what I am used to and to what I love about
Additionally the dependency upgrades and additional dependencies Owncloud
requires with each new versions make a backport pretty unfeasible. David tells
about 70 related packages and as I tested upgrading Owncloud debian packages
by the path David suggested, which didn´t work for me at that time, maybe due
to a misunderstanding on my side on his instructions in README.Debian which he
clarified after that, I ended up with a quite adventurous mixture of Debian
Jessie + Unstable. Thanks to the outstandingly excellent dpkg / apt packaging
framework I was able to downgrade it to plain Jessie after that and continue
running the server as Jessie again.
I know it doesn´t have to be that way.
For example Wordpress debian package, before there was a backport for jessie-
backports I just had the one from unstable installed. It needed just 2 other
packages from Sid, at the beginning it didn´t need any other packages from sid
at all, only later versions needed two packages. That is a software that is
feasible for backporting. And it has a backport. There has been some
reluctance about it from the backports team, as a previous backport was
cancelled, but the current one is maintained well. Also for drupal7 there is a
backport, not completely in sync with the version in testing currently, but
there is one for jessie and there is also one for wheezy.
Owncloud at its current state of development IMO is not feasible for a
backport – and its it not feasible for a backport it certainly is not feasible
for a security upgrade to a new major version of it. Cause even if David or
someone else did all the work to backport that 50+ other dependencies that a
new version of Owncloud need a new version of them, who on earth is going to
test it with all the other PHP related packages in Debian stable that use the
Now I don´t know an easy solution to this, but with the current way Owncloud
is developed, I get the impression that it is very difficult to provide any
sane backport for it or switch versions for Owncloud within security support
for Debian stable. Not impossible, but difficult.
So thats IMO why there isn´t one, nor why no one decided to go with the
Debian compromises on its stable policy already. For chromium and iceweasel
maintainers provide new upstream versions within stable security support. And
even though I think they may bend unbundling rules for packaging to some
extent by accepting that upstream bundles some stuff, by no means I have the
impression that they would need to upgrade 50-70 other packages just in order
to bring in an upgraded browser to stable.
> It is a mess. We all know it. We should look for solutions - because if we
> don't, as I've said a few times: distributions will become 'the thing you
> run a docker container on'. And indeed, Snappy, project Atomic - there is
> work going on in this direction.
I am still surprised at the certainity in which you claim to know the future.
My current conclusion regarding Owncloud is this:
I am not going to mess with it. Instead I prepare to remove it from my server,
before Jessie security support for it ends.
Why is that?
Cause the alternative would be this:
- I use a Linux container.
- I use upstream tarball or package which bundles almost all of the
- Instead of Debian security support for *all* packages, with announcement
mailinglist, with fixed CVEs mentioned, with Debian Security Advisories, with
debsecan vulnerability reporting, with cron-apt upgrade reporting, with
documentated limitations checkable with check-support-status from package
debian-security-support I would need to rely on upstream promise to provide
timely security updates for *any* and *all* of the bundled dependencies. Maybe
I could trust it, but I currently don´t know. Debian has a track record. I run
it since more than I bet 8 years on server VM and I am pretty confident no one
broke into my server. And we run it on a ton of servers for ourselves and
customers at my employer so I am pretty confident it is a repeatable
- I need to install each upgrade, mess manually with migrating crypto keys at
least once and what else upstream may come up with.
Now I ask you:
Are you kidding me?
Is this the model of doing things the future? Develop without any care of
maintainability just for the sake of bringing in new features really fast?
Thanks, I opt out with this model of upstream saves some work which then every
user of Owncloud has to do. I´d think its upstreams responsibility to do this
work, instead of relying that users will put up with it and having the work
that could be done *once* replicated about, well 8 million of times.
If you read this as a strong "Get your upgrades fixed!" then, yes, thats
> As I wrote in the other email - I feel there were two options: Debian would
> be flexible with the rules, making things work until, perhaps, ownCloud
> could be modified to fit the Debian rules (or perhaps these rules were no
> good fit, period). Or - no more Debian ownCloud packages. I don't know if
> the first option was ever considered - all I know is that we ended up with
> the second.
The rules of Debian is why I have it on the server and, no offense meant, no
OpenSUSE or Fedora. And no Linux containiner for every single app I want to
run on it.
I am happily running Debian Sid + some experimental packages on my laptop, but
on my server? Nope.
Wordpress can do it, Drupal can do it, Postfix can do it, Dovecot can do it,
Mailman can do it, Apache can do it, you name it can do it. For all of them
Debian provides seamless upgrades across distro-releases and for some even
backports, like Wordpress for example). No data loss whatsoever with any of
those so far.
I have security updates with CVE numbers in changelog, I have it all via apt,
I have it all work out of the box, I have releasenotes, I have sanity, I have
I can sleep well with all of it running on my server. (Well I wonder a bit
about Wordpress, but I hope just a few addons it may work out.)
Please I want this for Owncloud as well… or I really intend hard to look at an
alternative for it.
Back then I assumed that crypto support stuff was stable, but upstream changed
it twice, at least. Without a sane upgrade path. Back then I thought Owncloud
would focus on providing share file & sync and I can just install it and be
done with it. Actually I understand that even since Owncloud 8 its mostly
about share & sync, its still not installing and be done with it.
I now found that Owncloud appears to be like a tamagotchi that messes up big
time if I do not give it care and nudging and upgrades and stuff every half of
a year at least. I want to install this thing and be done with it. For three
years at least. And then upgrade it. With any possible pitfalls being
documented in README.Debian or release notes.
Does not seem that this is going to happen soon enough for Stretch at the
moment, a pity, cause I truly believe that Owncloud has something for it. I
chose it for some reason. It clearly offers a functionality I want. Yet, if
its not supportable for my server with any amount of sanity, its out.
And I don´t even know what I tell possible customers of Owncloud at the
company I am with. I for sure will tell them to use upstream packages after
what I learned here, but I do not intend to hold back what I think of upstream
policy on upgrades especially in the context of enterprise needs. Cause most
companies I do work with want to do it just like I do: Install it and *be
done* with it.
I bet with the current model there is not even a remote chance for Owncloud to
ever be included as a supportable package within SLES or RHEL. And heck for
Debian its just about 3 years, if one excludes Owncloud from Debian LTS
support, which I would clearly advise to do, not 10.
If the new web world is break things hard and break things often… I am clearly
willing to sit it out, to wait for some sanity to come back into the minds of
the developers of the web apps.
Cause in the end its my choice how my future will look. And no one elses.
There is no law that determines that distributions will be just a base
operating system for containers. There is no law that forces me to keep
Owncloud installed on my server. Its removal its just one apt purge call away.
I done this before with stuff, and I am willing to do it again if I am not
convinced I am willing to put up with the hazzle to maintain it.
Its the people who create Debian and Owncloud and its the users who create the
future. After DebConf 2016 in Heidelberg I have no doubt that Debian is there
to stay to be used as a distribution in its best sense. I also think Owncloud
will stay and thrive. But unless the approaches I see being used in Owncloud
development do not at least to some extent match with the amount of what I
call sanity I want for my server, I am not intending to continue to use it.
The barrier of entry for an application to be packaged within Debian may be
high, but I came to trust this entry barrier. It keeps out the stuff that I
would use more of my precious time to maintain it than I want. I want this
what I call quality. I am not living for my server. The server is there to
provide the functionality I want – with the least amount of work on my side.
In other words: The server is there to serve me… not the other way around. If
its in the Debian repo, I know, usually it is maintainable. I love this entry
That said I use rubygems for some things at work, like installing fluentd –
yet I would never put this directly in contact with the internet and I am not
really fond of having a packaging system inside a packaging system.
I agree there is an issue to be solved, and maybe even some changes in how
distros are created are important to make, but blindly adopting the crazy
break things often, break things hard, deploy every commit at the moment it is
pushed kind of strategy is not it… at least not for me. Maybe for a huge
company like Facebook this agile development approach will work really good
with a team of dozens of people to fix things up, in case someone messes the
app. But not for me.
Heck, even for Plasma + KDE Frameworks packages are quite maintainable. They
even extend their outreach to distros currently. If the desktop can do it, if
quite some PHP like Wordpress and Drupal apps can do it, if every other server
app like Postfix, Apache, Nginx, Dovecot can do it, why can´t Owncloud?
Whats up with you guys?
More information about the Pkg-owncloud-maintainers