[Owncloud] Owncloud on Fedora/RHEL 6

Mon Jan 20 12:56:57 UTC 2014

Hi,
I just wanna step in here to clarify some things. FYI: I'm the 'main' 
maintainer of owncloud in fedora. 

On Monday 20 January 2014 11:35:06 Klaas Freitag wrote:
> On 19.01.2014 21:06, Matěj Cepl wrote:
> 
> Hi Matěj,
> 
> > 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.
> 
> How about already released versions of Fedora? For example, will it be
> possible to provide _version_ updates of ownCloud to users of Fedora 20
> through Koji? AFAIK for released distros, only security fixes but no
> version updates are allowed?!

This is not the case for fedora. You are allowed to bump releases as you 
please. Actually the updates policy states otherwise but since nobody really 
enforces it, it's basically a maintainer decision [1].

> 
> If it is possible to ship version updates of ownCloud through the
> official Fedora channels within hours or days, we could immediately
> switch to Koji, as I said before.

Technically it's possible within hours but the main issue is bundling.

As you know distros try really hard to avoid bundling. So if:

A: the 3rdparty dep is already packaged
B: and is compatible with owncloud (version, patches)
C: can easily be integrated (read: I just delete the bundled lib in 3rdparty 
and add it to requires)

it would be very easy to track new owncloud releases in fedora. In reality of 
course it's not that easy:

- often php includes are all messed up with hardcoded paths. If you drop a 
3rdparty lib owncloud breaks, even if the system lib is installed. Adamw has 
created a set of patches to address this issues. There are even pull requests.
- also some libs are seemingly randomly patched (this time we had some fun 
with doctrine and ownloud6, after applying the patches to doctrine it works 
again but of course it took some time)

Another, more social, issue is: What to do with users that don't want to 
switch? I.e. you have a nice working oc 5 install and now your package manager 
wants to upgrade it, although oc 5 is still supported and receives fixes. Imho 
we would need for this case packages in multiple versions i.e. ownloud6, 
owncloud5, ... so there can't be unwanted upgrades.

All this takes quite some effort and my time is limited, after all I don't get 
paid :). And as long as those issues are not resolved I kinda see the point of 
an upstream rpm channel distributing vanilla oc releases, though of course I 
would prefer it to keep it all inside fedora...

> 
> >> 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 misunderstood. I meant: If the distro does not allow version
> updates, it dictates you more or less which version of ownCloud you as a
> user can use.
> 
> >> 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.
> 
> Haha, me neither of course. But we have to admit: Even though users are
> pestering their systems and probably get into dangerous situations
> without realizing that, Android as a system is hugely successful. People
> _want_ that. Unfortunately.
> 
> > 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?
> 
> Yes, please. It is useful to prepend the subject with something like
> [Packaging].
> 
> >> 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.
> 
> We used to maintain patches for Qt 4.6, but at some point of it was not
> longer reasonable. So hard to find a good solution. I am sure we're not
> alone with the problem on RHEL and, if you search, you find more project
> shipping their "own" Qt.
> 
> >> 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.
> 
> I know, all distros package gems, perl modules etc. But for the distro
> users, there are always the two alternatives: Do I use the distro
> package of the ldap gem (example) or do I use gem install which brings a
> newer version but conflicts with my installed other ruby stuff.
> 
> The philosophy behind in the ruby world is: Since using gem is so easy,
> we can provide new and incompatible versions very often and quick. Bad
> for "traditional" distro users.
> 
> >> 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.
> 
> Hmm, see what I mean? I am quite busy in implementing more cool desktop
> client sync features or fix bugs in there. So that is why our packages
> are not yet optimal: Nobody has time to make them really good. So
> everybody who has some minutes left: Please jump in and help!
> 
> regards,
> 
> Klaas
> 
> _______________________________________________
> Owncloud mailing list
> Owncloud at kde.org
> https://mail.kde.org/mailman/listinfo/owncloud

[1] http://fedoraproject.org/wiki/Updates_Policy#Philosophy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/owncloud/attachments/20140120/e0b7116c/attachment.sig>