[Owncloud] Owncloud on Fedora/RHEL 6

[Matěj Cepl]

(sorry, for the late reply ... I have sent it to the list with 
wrong From: address and it apparently got lost)

On 2014-01-13, 21:25 GMT, you wrote:
> And here is the problem: Fedora 19 (!) seems to provide 
> ownCloud 4.5.13 which is about nine month old. That's not what 
> people want. They want ownCloud 6. And we seek a way to 
> provide them, even if they are on Fed19.

And if insted of pushing new version to your system (or OpenSUSE 
build) you would push it to the Koji, then you would have build 
for Rawhide and -testing distros in the same time. When I was 
working as part of the team dealing with Mozilla programs 
(Firefox and Thunderbird) we were proud to have 0day upgrades.  
I don’t see the reason why you couldn’t have the same in Fedora 
(note, Fedora is not RHEL so updates and rebases are mostly 
decision of the maintainers).

> Yes, I know, I worked long enough for another distro. But one 
> of the distro communities problems is that they don't really 
> face todays reality: As said above, people want to have 
> up-to-date apps. And if a new version (!) comes out, they 
> wanna use it and not hear "Well, you have a nine month old 
> version, and we will provide you with security fixes. Be 
> happy!"

I am not sure which distro you are talking about. If you think 
Debian/stable, then RHEL is not exactly like that. Of course, 
stability is very very important, but it is not exactly 
completely dead frozen stability as with the Debian/stable (and 
this is not meant to say anything against Debian maintainers ...  
when I see how incredible amount of work my colleagues have to 
spend on keeping RHEL together, I fully understand Debian with 
its limited resources is not capable of such feat). Notice that 
we have many server side (even PHP) programs in EPEL 
(https://fedoraproject.org/wiki/EPEL), and if you think that 
keeping up with WordPress 
(http://koji.fedoraproject.org/koji/packageinfo?packageID=4118) 
is so simple, then you are badly mistaken. For example, we had 
to create php53 for it (or because of Zarafa 
http://koji.fedoraproject.org/koji/packageinfo?packageID=9907, 
another not exactly simple package to maintain).

> They don't wanna have their operating system platform having 
> dictating the versions of the apps they're using.

??? Nobody dictates you anything, if you put you hand down to 
the shovel.

> You might want to check how that is on other, successful 
> platforms like android how it works there. Time has changed 
> a bit, and we as distro guys shouldn't close the eyes IMHO.

If you think that the mess of multiple copies of huge libraries 
bundled in individual packages half of them unmaintained (a mess 
from which Java folks are trying to get out ...  
http://openjdk.java.net/projects/jigsaw/ ... so far 
unsuccessfully) and thus half of them with unpatched security 
vulnerabilities makes me envious, then you are sorely mistaken.  
I don’t mind if people put such mess on their phones (their 
problem), but to have something like that on server doesn’t seem 
like a good idea. Yes, many people do it, but probably mostly 
because they have no other choice (especially in Java world 
which lacks appropriate technology, 
http://openjdk.java.net/projects/jigsaw/ still hasn’t 
materialized), but a part of the Fedora’s mission is to provide 
excellent engineering.  This doesn’t seem like a way to get 
there.

BTW, so far, RHEL customers seem to agree with this opinion.

> Of course not. This is speed: If ownCloud upstream releases 
> a new ownCloud version, the users can install it through their 
> distro package manager an hour later. 6.0.0a on Fedora 19.

As I said, as the old rabbi said ... it depends just on you.

> Whooohooo, now you're starting! Please calm down a bit, we're 
> not doing bad stuff intentional.

I didn’t say that. Just because you are doing your separate 
community, you didn’t have time and resources to do it 
correctly. Completely without any sneering, how should I report 
bugs against your RHEL packaging? GitHub Issue tracker?

> a) RHEL 6 ships Qt 4.6 IIRC. That is so much outdated that we could not 
> backport the client without taking too much away. And RHEL not being 
> desktop system no 1 on the planet, we decided to ship an useful Qt 
> version in /opt/. I know, distro people hate that, but please consider 
> reality here as well. What do users want? A _working_ solution. And I 
> don't think that the Qt in /opt/.. steps in the way of anything else on 
> the system as we also provide wrapper scripts.

What do users want? Well, users of RHEL want also _maintained_ 
solution. Are you certain you will maintain Qt (it is a huge 
library) as well as Fedora maintainers? As I said we have php53 
package (for EPEL 5; don’t tell me how RHEL-6 is obsolete before 
supporting RHEL-5 ;)), or perhaps somebody can think about 
patching reasonable subset of owncloud-client to work with old 
Qt, or perhaps old owncloud-client can be patched to work with 
new server API. Something. Reasonable people are able to 
negotiate solutions for their problems.  

> b) issue tracker: https://github.com/owncloud/mirall/issues - not 
> exactly hidden...

OK, point taken.

>  > I don’t know where this mentality of splitting distro into
>> thousand of incompatible subcommunities growth from? Ubuntu,
>> with its PPAs, because Canonical doesn’t allow you to fix bugs
>> in the core libraries, or what (not trying to libel them, just
>> really honestly don’t know why you need to separate yourself
>> from the rest of the Fedora/RHEL community)?
> It's not that we want to separate, why should we? We see the benefit of 
> stable and maintained distros. But as I tried to explain above: We want 
> to provide our users with very current binary packages, as outlined, 
> that is one of our main goals. As soon as we can solve that requirement 
> with the main distros, we would love to drop our own packages.

Reasonable people are able to find solution for their problems.  
I believe most Fedora maintainers are reasonable people (yes, 
I know some exceptions ;))? Why do you think you won’t be able 
to work with them?

> Have you thought about how other web oriented platforms solve this 
> problem? Why does the ruby gem stuff exist? Because they want to be 
> faster than the distros update cycle, as we want. And I think you agree 
> with me that a third party repo with proper rpms is the better solution.

https://admin.fedoraproject.org/pkgdb/acls/list/*rubygem* well 
not exactly shabby. The same goes for python-* and perl-* or 
php-*. And no, I don’t think we should copy complete 
http://rubygems.org/ (or https://pypi.python.org/pypi, or 
http://www.cpan.org/, or etc.), but I think we can have 
reasonably large set of main packages that reasonable set of 
applications (which certainly includes owncloud) can be 
maintained in Fedora. If you want to have installed something 
obscure, then by any means use gem, pip, cpan, composer for 
them.

> Again, I am happy to drop our Fedora/RHEL packages if we can 
> manage to provide version update packages very fast for 
> already released distros.

See above.

> As long as we can not, I think we need to keep up our third 
> party repo for those who are interested in new versions on 
> your distro. If our packages are broken, sorry, please help us 
> fixing.
> How about coming you come up with concrete things to fix?

I am sorry, I have already too much on my plate, and I don’t 
know any PHP, so with regards to ownCloud I am just (very happy 
and excited) pure user.

> Having that said, I wonder if there is a cross distro dev room 
> on FOSDEM this year? It would be great if the distro guys 
> could discuss how the problem can be solved how version 
> updates of leave packages  can provide fast through the 
> standard distro channels. We're not the only ones with that 
> problem.

Yes, that could be interesting. I am just not sure how much of 
this is something which could be resolved with some high-level 
ideas. I am afraid it is just hundred of small individual 
problems every one with its own solution.

Best,

Matěj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/owncloud/attachments/20140119/12743836/attachment.sig>