Nextcloud 12.0.3 #158
Comments
|
My first instinct was to check and see if the EPEL package could be updated to 12, but version 11 and 12 both require at least PHP 5.6. Since EPEL packages are restricted to what is available in RHEL, that's a dead end. I am investigating if this would be feasible as an IUS package. However, I recommend you temper your expectations. Nextcloud is notoriously difficult to package. Fedora Rawhide doesn't even have Nextcloud 12 yet. |
|
If you like, let me play with it and see if there's a simple reworking on the nextcloud-10 spec file that suffices. Nextcloud bundles most of its php module dependencies, so they needn't exist as rpms. I don't see any basic php dependencies that aren't already provided by php71u (but I'll need to test it to be sure). |
|
I did some research and found that there are several problematic dependencies.
Relevant bugs: If we wait for Rawhide to update to NC12, php-icewind-searchdav and php-icewind-smb2 will exist in Fedora and we can ask for EPEL7 branches of them. Then we can revist this and see if the other dependencies can be bumped. |
|
In reviewing the spec file for the existing EPEL release of nextcloud-10, it looks like the packager didn't require that all the dependent composer packages be available in EPEL. The spec file simply takes the nextcloud release, which bundles all its required php packages, and deletes just those bundeled packages that happen to exist as EPEL packages, hacking the autoload to refer to the EPEL dependencies where they happen to be available from EPEL. So, one option would be to simply package the nextcloud 12 as it is built, with all its bundled php packages, and just not depend on any EPEL php packages (the spec file would be much simpler). It's not very big, and if there server doesn't support anything that requires those packages from EPEL, there is no space penalty at all. (I added a similar note to https://bugzilla.redhat.com/show_bug.cgi?id=1433919#c16) |
|
The only thing I see are bundled javascript libraries ("State of javascript in fedora right now is too painful to unbundle"). The spec file indicates that all PHP libraries are unbundled ("Explicitly remove the bundled libraries we're aware of"). Which PHP libraries are you seeing that are left bundled? |
|
Carl the last I looked there were new things to unbundle for NC12 ... the
state of the unbundling of NC10 can't be considered in that.
And that's not the case that we permitted any bundling for NC10 of PHP
libraries ... every PHP library was unbundled.
…On 14 November 2017 at 14:20, Carl George ***@***.***> wrote:
The only thing I see are bundled javascript libraries ("State of
javascript in fedora right now is too painful to unbundle"). The spec file
indicates that all PHP libraries are unbundled ("Explicitly remove the
bundled libraries we're aware of"). Which PHP libraries are you seeing that
are left bundled?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#158 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AC5XzLbdBxjjgcX1Fm4f1qJHW6vx-nz2ks5s2aHBgaJpZM4QCAhN>
.
|
|
On a different note, I have some concerns regarding the upgrade process. The Nextcloud upgrade documentation raises a few flags. Multiple times they stress the importance of backups as downgrades are not supported. 3rd party applications need to be reviewed for compatibility and disabled before the upgrade process then re-enabled after the upgrade. The upgrade process is disruptive, can also takes hours and could fail. As I read on the documentation, it seems the upgrade process is too fragile to get handled within the rpm. If that is the case, I am not sure how to handle upgrades. |
|
We never rub the migration automatically.
RPM only puts the files into place and the administrator needs to carry out
migration tasks.
…On 14 Nov 2017 5:05 pm, "b-harper" ***@***.***> wrote:
On a different note, I have some concerns regarding the upgrade process.
The Nextcloud upgrade documentation
<https://docs.nextcloud.com/server/12/admin_manual/maintenance/upgrade.html>
raises a few flags. Multiple times they stress the importance of backups as
downgrades are not supported. 3rd party applications need to be reviewed
for compatibility and disabled before the upgrade process then re-enabled
after the upgrade. The upgrade process is disruptive, can also takes hours
and could fail.
As I read on the documentation, it seems the upgrade process is too
fragile to get handled within the rpm. If that is the case, I am not sure
how to handle upgrades.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#158 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AC5XzKWKuD1-4WdEeJL8wSdtpmnV5gmmks5s2ceggaJpZM4QCAhN>
.
|
|
Just a few things to note: Nextcloud 13 Beta 1 is now available |
|
The IUS project has reached it's end of life, and will not be addressing any more wishlist requests. |
What new package do you want?
nextcloud 12.0.3
Why?
EPEL7 has nextcloud 10.0.4, which is "no longer supported". Ref Changelog. Version 12 has numerous security improvements and collaboration features I'm interested in, along with the performance improvements of running nextcloud on php71u.
Testing
I agree to test the new package to ensure that it works as expected.
The text was updated successfully, but these errors were encountered: