Will Nextcloud be "inviting" to distribution packages?

For those following this particular discussion thereā€™s a preliminary package in COPR now for testing use.

This will almost certainly be the basis of my review request there coming up soon:

https://copr.fedorainfracloud.org/coprs/jhogarth/NextCloud/

I havenā€™t yet decided what to do with OwnCloud in Fedora/EPEL or if Iā€™ll try and do an automated switch from oC to nC there.

1 Like

Iā€™d say that providing up to date packages is a great idea and Iā€™d like to invite distributions to do that.

So distributions with a rolling model or a short release cycle like Arch, openSUSE Tumbleweed, Fedora or Debian Unstable/Testing could easily include Nextcloud packages and - please, guys and girls, do. Anything we can do to help, ask us!

For a more LTS focused distribution there are two problems:

  • long term bug and security fixes are something very few volunteers want to work on (most barely fix bugs in the stable release but only in development versionsā€¦).
  • Nextcloud canā€™t skip upgrades. And I donā€™t think it is OK running people through 5-10 upgrades at once at the end of the period.

It wonā€™t be easy to find people willing to do bug and security fixes for 10 years. I sure wonā€™t be willing to force volunteer developers to backport every fix for that long. A low barrier to contribution to Nextcloud is important to us.

We want to make it possible to skip releases, so that concern might go away in a future release, but weā€™re talking at least 2-3 releases from now, I think. An alternative would be to built a hacky way to skip upgrades which risks usersā€™ data - something we would get very upset about (again). Usersā€™ data is holy, not risking it is rule 1 of Nextcloud.

But it was planned: Nextcloud and its planned update improvements ā€“ Lukas' Random Thoughts
Did you drop this idea?

PHP itself has 2 years full support + 1 year security updates (https://secure.php.net/supported-versions.php). CentOS backports fixes but I donā€™t know if they do it for all sorts of web application.

Ubuntu LTS support (5 years) only applies for packages from main. There are likely some unsupported packages: ubuntu-support-status --show-unsupported.

NC releases receive security updates for 18 months, thatā€™s a considerable period of time. If you can skip major upgrades this would mean you must do a upgrade every 18 months. But how to implement this into the distribution packages? Would it help to provide a NC LTS with a support cycle of letā€™s say 2 years, and cut support a bit for other versions? To comply with the release cycle of Debian/Ubuntu it should be rather 3 years. Or they have to do a major NC upgrade at mid-term?

1 Like

no, Iā€™m just saying it isnā€™t implemented yet.

With regards to the 18 months, thatā€™s waaaaaaaay not long enough for Debian, RHEL or SLES and, indeed, even Ubuntu LTS with its 5 yearsā€¦ RHEL and SLES are supported for a decade or so.

The distroā€™s could decide to do major upgrades during this period, that would solve the problem of course.

Not sure, but i remember RHELā€™s support is not covering software like owncloud. So I donā€™t know of examples where 10 years would apply. Never the less: Thatā€™s the question that distributions answer when packaging software. I donā€™t think that known security issues would just remain unfixed in Debian stable. The seperate Debian LTS team might just drop support for Nextcloud. As with a direct Nextcloud installation you would have to upgrade, in this case your distribution from LTS to old-stable or stable.

Still for me the question remains, will you threaten downstreams with trademarks again?

You could save space by using ā€œfolksā€ while being even more inclusive :slight_smile:

It would be great if you wouldnā€™t mix things up. Owncloud was distributed via the ā€œuniverseā€ repository. Itā€™s not officially supported, and also practically there is not LTS support at all. You canā€™t blame other distributions for Ubuntu having such a nontransparent security support policy (VLC player and Chromium are also in ā€œuniverseā€).

2 Likes

Are there more than two biological sexes :D?

Well anyways, Iā€™m totally confused now with all the different support periods. Does that mean we keep everything as is and let others worry about it?

Not in principle, but we havenā€™t done it before either. Only if people do stuff that would make Nextcloud look bad - for example, things that threaten user data, or adding spyware. But thatā€™s always been a rule in our trademark guidelines.

RHELā€™s support doesnā€™t cover Nextcloud or ownCloud, the idea is that those companies get paid by customers for support of their software on RHEL.

So your company deploys RHEL 7.2, which has 10 years RH support. You then buy Oracle version whatever, which also has 10 years for that RHEL release. And you get Software X, also 10 years supported with Oracle version whatever and RHEL 7.2. Now you have a platform you can use for 10 years, and you pay gold for that to Oracle, RH and the vendor of Software X because they need money to pay their engineers to work with stuff so old nobody sane wants to touch it with a 10 foot pole.

So here is a concrete invitation: we provide a space for anyone to built distribution packages:


Ask and youā€™ll be added with the karma to get stuff going.

If you prefer to work on this within your distributionā€™s structure that is totally cool with us too, of course. We just want to facilitate!

:heart_eyes:

Now get crackinā€™!

3 Likes

This isnā€™t solving anything. The problem has never been to find a repository/bugtracker/infrastructure to develop packages. The problem is NCā€™s attitude towards downstreams users who just want to apt-get install nextcloud and know itā€™ll work.

1 Like

Well, our attitude is: ā€œit would be awesome to have, how can we help someone who has packaging knowledge to make it happen?ā€

Not sure how that is a problem :wink:

In any case, there are packages: https://repo.morph027.de/
See
https://morph027.gitlab.io/post/nextcloud-install-via-packages-on-jessie/

Not sure how we missed this :cry:

Try them, tell me if they work, please!

1 Like

How can you help ? Easy ! Allow the packaging guy to integrate NC nicely within its distribution, i.e.:

  • have some stable maintained versions.
  • allow migration from one stable version to the other (even if the migration script is written by the distro maintainer).
  • do not threaten people if they donā€™t maintain your software the way you would like them to.

have some stable maintained versions.

Check

allow migration from one stable version to the other (even if the migration script is written by the distro maintainer).

There is currently still code that canā€™t deal with this. Also distro maintainers in the past did not write migration scripts but they are of course free to do so :slight_smile:

do not threaten people if they donā€™t maintain your software the way you would like them to.

There never were threats but people were displeased with communication and like you pointed out some distro maintainers turned off the check while not writing migration scripts so they broke peopleā€™s installs.

1 Like

Hi all,

If I may, I believe the 2 issues of
1.Having a ā€œstableā€ system
2.Making sure no obsolete NC installs are left around
can be addressed.

You have a lot of packages that require frequent updates: anti-virus systems, etc.

In Debian for example, there is a repository called ā€œstable-updatesā€, for packages matching the following (from Debian website):

-The update is urgent and not of a security nature. Security updates will continue to be pushed through the security archive. Examples include packages broken by the flow of time (c.f. spamassassin and the year 2010 problem) and fixes for bugs introduced by point releases.
-The package in question is a data package and the data must be updated in a timely manner (e.g. tzdata).
-Fixes to leaf packages that were broken by external changes (e.g. video downloading tools and tor).
-Packages that need to be current to be useful (e.g. clamav).

So if the package maintainer manage to convince NC belongs in stable-updates, then they can get their more frequent updates without compromising the whole system stability.

I assume similar mechanisms exist for other distributions?

What @BernhardPosselt said.

If you mean, with point 2, that one should be able to skip a release on upgrading, this is work-in-progress but quite hard. 12 will most likely make big steps in that direction, not sure if itā€™ll be ready yet, though.

With regards to the other points - weā€™ve had stable releases since we started, that is what 9, 10 and 11 are. And when did we ever threaten people? If you refer to the packaging debates earlier with Debian - wellā€¦ First, we might still be unhappy if a distribution isnā€™t careful with user data, or seems to be going in that direction. Bu weā€™re a different project, different management i particular. So we wonā€™t be making our own packages anymore nor will we tell people to use those. Entirely up to the distribution now. That should be blindingly obvious by now - we donā€™t and wonā€™t be packaging.

And if a distribution breaks packaging, well, we have no expertise doing better. We might suggest to use another distroā€¦ Which is what Iā€™d currently recommend - if you want packages, use a distro which provides and maintains them. Simple.

WRT Debian packages, @morph027 has been so kind to create them and is keeping them up to date: http://repo.morph027.de/nextcloud.php

Iā€™m adding it to our install page. Fedora, @James_Hogarth - are you over on Nextcloud, if so where should I link to? https://copr.fedorainfracloud.org/coprs/jhogarth/NextCloud/ for now?

Hi guys,

@jospoortvliet - Sorry this took a while but there was a bit of $life in the way for a couple of months and we wanted to be rigorous with the packaging from the start rather than go through the major refactoring again that we had with owncloud.

There are now nextcloud 10 packages that have been approved and in the testing repositories for Fedora and EPEL7

https://apps.fedoraproject.org/packages/nextcloud/overview/

The package includes migration instructions from owncloud if there is an existing instance you want to convert and a more detailed write up is available here:

https://www.hogarthuk.com/?q=node/17

Weā€™re now hard at work with the newer dependencies needed for nextcloud 11 (symfony 3+ being the biggest one we are working on) and there will be an update to that in due course.

The packages should reach the stable Fedora repos in about a week and EPEL7 stable in about a fortnight.

Thanks for your patience with this and if thereā€™s any issues you encounter with these packages please do report them at the Fedora bug tracker: https://apps.fedoraproject.org/packages/nextcloud/bugs/

Regards,

James

2 Likes

Great news!
Will it be available for CentOS either? :slight_smile:

It is in the EPEL7 repos so easy to install on CentOS/RHEL 7

Due to PHP version limitations I canā€™t build this there on EL6

Do note that with the min PHP version being bumped in nextcloud 12 to 5.6 there cannot be an EPEL7 package for that then.

Iā€™m not 100% sure if Iā€™ll continue to maintain nextcloud 11 in EPEL7 for as long as it gets updates or if itā€™ll be retired at that point - but thatā€™s still some way off and Iā€™ll have an article with the options available to people nearer the time of that event.

2 Likes

Now that we have nextcloud 12, what is the strategy to get it packaged on Fedora ?

Taking in consideration that only nextcloud 10 has been packaged with Fedora 26, this is becoming quiet weird !

Is the best to go away from Fedora packaging and use directly the tar ball ?

This is indeed very very bad. Nextcloud 10 is EOL with the last public release in August, it shouldnā€™t even have landed in a new Fedora release! This just confirms the low quality (aka Red Hat playground) of this distribution to allow something like that.

It would be better to remove the package and use the official tarball to be on the safe side.