[Pkg-owncloud-maintainers] I am using distro packages and I tell you why

[Martin Steigerwald]

Jos,

Wow. Seems I received a ton of frustrations that I didn´t contribute too.

I am not sure whether it makes sense to spend a lot of energy in my answer, 
but I want to at least reply to some of your answer.

Am Montag, 4. Januar 2016, 17:52:45 CET schrieb Jos Poortvliet:
> On Monday 04 January 2016 12:58:02 Martin Steigerwald wrote:
[…]
> > I do not comment directly on your blog as that requires a Google account
> > and I deleted mine more than a year ago for various, I think, good
> > reasons.
> > 
> > I refer to this blog:
> > 
> > Virtual Machine, Zip Files and Distribution Packages
> > 04 January, 2016
> > http://blog.jospoortvliet.com/2016/01/virtual-machine-zip-files-and.html
> > 
> > 
> > In it you argue against using distro packages and criticize their update
> > policy, yet:
> > 
> > I started out with a Debian distro package and then wanted to switch to
> > upstream packages to upgrade from 7 some 8.0.1 something version back
> > then.
> > 
> > It was a *complete* disaster. In the end I rolled everything back.
> > 
> > Why?
> 
> Because, as I explained in the blog, Debian tried to fit a square peg (web
> app) in a round hole (made for old style C apps). It didn't fit, they
> banged on it until it DID fit, and now everything is broken.

I am not willing to spend my energy into this is correct and this is broke. As 
long as I stuck with Debian provided packages everything was fine

Both approaches are different and thats about it.

From your response I gather that you are not willing at all to find some 
common ground here.

> > The Debian provide package is actually a Debian package: It has the
> > configuration for Owncloud in /etc, where it belongs and everything else
> > where it belongs. It is what I call *properly* packaged. The Owncloud
> > provided package is just like a tar.gz inside a Debian package. It just
> > unpacks everything to /var/www/htdocs or something like that. It is no
> > package that even remotely meets my quality expection for a Debian
> > package.
> 
> Ah, so you want executable code in /etc? Yes, config.php is executable. And
> why, because of some outdated policy? So you can backup your configuration,

First off I think that even a PHP web app could parse the config. But wait, 
maybe PHP is too slow for that? Then, I have this with Debian packaged 
Wordpress already and it works fine here. Third I manage my /etc within Bazaar 
to document changes. And fourth I do believe that in documentroot of the 
webserver only stuff belongs that the webserver should be able to access 
instead of creating a huge .htaccess file mess.
 
> It is 2016. This is a web app. Your conventions do not apply. Live with it
> or become irrelevant. I know, the choice for option 2 was already made.
> Sorry, this is a flame, but there is a reason for Docker's popularity: the
> distributions have failed to keep up.

Well as David informed me Debian experimental has already 8.2.2 – and indeed 
it has 8.2.2~dfsg-1 already –   and the 8.0.10 package in his people page is 
for updating for crypto users. Anyway, from what I gather from your answer I 
will just do one thing with your recommendation: Dismiss it. And use the 
irrelevant package. Cause in the end, even in a systemd world, I as a server 
admin decide what will happen on my server. Later one I give some reason why I 
choose this path. (Also the server still runs with sysvinit for now. On Debian 
Jessie.)

> > Yet even 8.0.10 is dated already I agree with that.
> 
> Yes. You are making the life of users harder: we do not support upgrading
> while skipping a new release anyhow, so if the new Debian release ships
> with ownCloud 8.2 or 9.0 then users will be unable to upgrade! You're
> backing them in a corner by sticking to such an outdated version.

Well, for now the 8.0.10 is there for updating purposes. David wants to find 
another way to do it, but for now this works according to him.

> I didn't complain, I warn users not to use something which is very likely to
> get them in trouble. You already pointed out that you have trouble
> migrating from ownCloud Frankenstein to ownCloud Proper.

Okay, so you think it the other way around. For me your ownCloud packages do 
not even meet basic Debian package quality guidelines. For you, the Debian 
packages version of Owncloud is a Frankenstein one. Not much common ground I 
see in there. A tarball in a deb like package is not a proper Debian package. 
I stand by that.

So I agree to disagree with you.

> > Did you ever talk to the distro teams about this? Did you ever try to
> > cooperate with them before considering to write your blog post?
> 
> The thing is that collaboration has to be with every distribution on their
> own infrastructure. That doesn't work, obviously, for a upstream project.
> There's a beautiful solution for collaboration - github. And a
> github-for-packaging, the Open Build Service. But Debian ain't interested.

Are you serious about this? You really want Debian to dismiss all of their own 
infrastructure to use… wait… Github and Open Build Service? Especially Github 
which is a proprietary platform? If you understood a thing about Debian you´d 
understand that this is asking Debian to completely abandon on of their core 
principles of using free software also for development.

> And honestly, I'm no packager so I don't want to dive deep into this or put
> work on it, just warn people not to use Debian packaged ownCloud.

Okay, then maybe it would be better if the discussion continues with the 
actual upstream Owncloud packagers.

> This isn't OUR problem. This is a problem which has been getting clearer
> over the last 15 years, distributions have not done anything about it so
> Docker and the  GNOME and systemd team and others are now solving the
> problem for the distributions by making containers which have everything in
> them.

And triggering a ton of friction in the process. systemd is not the holy 
grail, and I am pretty confident that the test of time will show this. Anyway, 
lets avoid in morphing this into yet another systemd discussion.

> > I think unified packaging would benefit everyone. Even if the 8.x packages
> > would not be in jessie-backports, you could provide them via your upstream
> > repository and if they are compatible with the Debian packaging, with some
> > coordination it would be possible to switch between them. I´d even be
> > willing to switch over and test them once I am confident that they won´t
> > break my existing setup in inventive ways by being totally incompatible.
> 
> I'm not the guy packaging and if our packager has time - that'd be cool. If
> you guys ran your own OBS, we could connect ours to it (long live
> federation of the web) and we'd have one convenient infrastructure where we
> could all collaborate on! How about that?

From what I gathered so far is if what you refer to with Open Build Service 
was formerly OpenSUSE Build Service, then it doesn´t meet basically quality 
and build requirements for Debian packagers. I do not recall the details so 
far, but I heard this more than once in talks with Debian maintainers.

> > So or so, Owncloud 7 just works for what I used it for and I´d prefer not
> > to have to upgrade to a major version every year or even shorter.
> > Especially when updates are not just smooth apt upgrade & update
> > experiences, like they are with Debian packaged Owncloud so far. Even the
> > database upgrade is done on package upgrade and I do not have to trigger
> > the update from a webbrowser as with Debian packaged wordpress for
> > example. So from what I can see Debian´s own Owncloud packages are very
> > well done.
> 
> I'm sorry you don't want to upgrade regularly, but you'll have to. You can
> group it if you like, but there won't be any skipping of releases anyhow so
> your choice is to either spread it out and stay a bit close to upstream or
> to group your upgrades, do them once a year or so.

Okay, so in your world I would grab owncloud on your site, wordpress on 
wordpress site, another web app on a third side and loose all of the 
advantages a distributions gives me by having one central source for upgrades?

Owncloud might have its on in place update, Wordpress wants an FTP login to 
upgrade itself, and another web app needs me to download a tar.gz from 
somewhere, probably even an unsigned one. Am I the only sysadmin who thinks 
why on earth shall I do that?

How is this different than upgrading a Windows system where I have to do 
different steps to update each and every third party application? Why on earth 
did I choose a distro like Debian in the first place? Cause the package 
maintainers take care of providing me all updates I need from a central 
location.

By no means this concept is irrelevant to me.

> And yes, we don't let the upgrade run in the packages for a reason: it
> breaks on some systems. We're working on a new upgrade system to fix this,
> but that's a different story. And another reason not to use distribution
> packages.

A bug or limitation in your software as a reason not to use distribution 
packages? Interesting standpoint if you ask me.

> > I understand the different policies and goals here. Upstream wants to move
> > fast, Debian wants to provide a stable experience for its users. Yet, just
> > barking at each other, ignoring each other or trying to drag users on the
> > own side is just is everything else but constructive. What about looking
> > for common ground and ways to cooperate instead – for the benefit of
> > everyone involved? Especially as Owncloud already has some longer
> > supported versions out there.
> 
> We can collaborate. On a platform made for collaboration. There is one
> (OBS), I haven't seen any others but hey, an alternative would be welcome,
> provided it is actually better of course. I don't think it is reasonable to
> expect upstream projects to work not only on packages for 15+ distributions
> but also do that with 8 different toolsets on 6 platforms.

Hmmm, in Debian more than 1000 developers cooperate. Granted maybe the 
accessibility of the Debian infrastructure could be better, but still I as a 
maintainer for some packages didn´t find it hard to contribute. Harder it was 
to really provide quality packages, but from what I can see its worth it, even 
if I sometimes wonder whether Lintian really has to be that picky about 
things. But in the long run I think thats good to have. Cause quality matters.

> Sorry to be harsh, but I've given up hope that the distributions will let
> anybody drag them kicking and screaming in 2016.
> 
> If we're to collaborate, I suggest the debian ownCloud packager(s) to start
> a conversation in debian about:

> * adopting guidelines which work with web
> apps (when it comes to where to put files, splitting up what and where, and
> dealing with upgrade cycles faster than the distro)

> * creating or adopting
> a open, transparent platform where distribution and upstream people can
> collaborate on creating packages.

> * synchronizing policies, guidelines
> etcetera between distributions so the above can be cross-distribution and
> SAVE work rather than create it.

All good points. But real colaboration also means to fine a common ground. A 
common ground is usually different from only one sides ground. If you expect 
distros to completely abandon what just works for them quite well completely, 
thats not finding common ground.

A start would be to clearly state the needs of upstream and the needs of 
Debian and to honestly look at where there would be ways to cooperate. I got 
quite some more replies only to the Debian owncloud packagers list, from 
people that apparently see no sense to discuss about this with you from 
previous encounters. Yet one of the people who replied thinks about suggesting 
to you that its completely within the reach of Owncloud upstream to provide 
Debian packages that actually meet the guidelines.

> Sorry that you get such a rant back to a nice email. As openSUSE community
> manager I already got the smell of this mess so there's some frustration
> ;-)
> 
> Let's hope 2016 brings solutions. Even if that has to be in the form of
> containers...

Well I had hoped that with my mail I may invite some change, but change can 
only happen when each side tries to understand the goal and needs of the other 
side and when there is a sincere willingness to find a common ground.

From your answer I think there isn´t. So it may be wise to just stop the 
discussion here again to spare energy on both sides. If there is no 
willingness to find common ground, then it is best to agree to disagree.

The result of this from my personal case will be that I dismiss your 
recommendation completely, and do the update path David described to me. Cause 
up to now upgrading the Debian package did just work out okay for me.

So like it or not, but I as a Owncloud user still get to decide whether I use 
your recommendation, or just dismiss it. At least the Debian packagers do not 
seem to be that vocal on their blogs about upstream decisions they dislike.

Thanks,
-- 
Martin