[Pkg-owncloud-maintainers] Bug#816376: Bug#816376: Unfit upstream

Jos Poortvliet jospoortvliet at gmail.com
Thu Mar 10 13:31:54 UTC 2016


On woensdag 9 maart 2016 23:51:16 CET Martin Steigerwald wrote:
> 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 issues.
> 
> 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"
> argumentation crap.
> 
> 
> 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 Debian.
> 
> 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 same dependencies?
> 
> 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
> Iceweasel approach.
> 
> 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
> dependencies.
> 
> - 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 experience.
> 
> - 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
> exactly it.
> 
> > 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 barrier.
> 
> 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?

Martin,

I agree far more with you than you seem to think. While I don't share your 
optimism with regards to how much better the situation is with other web apps 
on Debian (did you actually read [1] ?), reality is indeed that the ownCloud 
developer community has not given priority to supporting the needs of Debian.

Sadly (?), I think that a user poll asking "comments and tags vs re-locatable 
config file and more conservative 3rd party updates" would not end up favoring 
what Debian would like to see so unless volunteers step up to change things in 
this regard, it can be a while.

That makes ownCloud still a very popular, useful and secure application, 
unfortunately not available in Debian. Luckily, we have packages.

Cheers,
Jos

> Thanks,

[1] https://statuscode.ch/2016/02/distribution-packages-considered-insecure/

-- 
Disclaimer:
Everything I do and say is based on my view of the world today. I am not 
responsible for changes in the world, nor my view on it. Everything I say is 
meant in a positive and friendly way, unless explicitly stated otherwise.
find me on blog.jospoortvliet.com




More information about the Pkg-owncloud-maintainers mailing list