On Wed, Apr 4, 2018 at 12:05 PM James Hogarth <james.hogarth@xxxxxxxxx> wrote:
On Wed, 4 Apr 2018, 16:37 Stephen Gallagher, <sgallagh@xxxxxxxxxx> wrote:On Wed, Apr 4, 2018 at 11:34 AM James Hogarth <james.hogarth@xxxxxxxxx> wrote:
Am 04.04.2018 um 16:51 schrieb James Hogarth:
> Last bit to debug before I can start testing an update of OC and NC is
> why my automated setup explodes with:
>
> PHP Fatal error: Declaration of
> OC\\Files\\Storage\\Local::copyFromStorage(OCP\\Files\\Storage
> $sourceStorage, $sourceInternalPath, $targetInternalPath) must be
> compatible with
> OC\\Files\\Storage\\Common::copyFromStorage(OCP\\Files\\Storage
> $sourceStorage, $sourceInternalPath, $targetInternalPath,
> $preserveMtime = false) in
> /usr/share/owncloud/lib/private/Files/Storage/Local.php on line 42"
because "$preserveMtime" is missing in one declaration and you must have
missed 1.5 years of PHP 7.0/7.1/7.2
"Declaration of ** must be compatible with **" is pretty clear and
nothing new, that was even a warning with PHP5 on a proper setup with
error_reporting = E_ALL for many yearsYes the error is clear... the fixes to get this working are suddenly nontrivial when I need to test a bunch of stuff in spare minutes between $realjob tasks.Keep in mind this is not my code... this is owncloud code that I'll need to write maintainer patches for to ensure it works on F27 and F28 ... at times this means backporting changes ... especially where major php version changes are concerned.This isn't usual - indeed at a Fedora release that has a major PHP update much of my time will be spent on tackling issues like these.I expect to spend 3-4 hours in bed tonight into the wee hours of the morning getting the basics in place so the current version can be safely installed on F28 and still run on F27 for both owncloud and nextcloud ... and then we can look to the major updates.Hopefully this will become easier once we get the PHP maintainers to move over to building Fedora Modules. Then we can decouple the PHP updates from the Fedora release and we can tie the NextCloud streams to a known-working PHP stream._______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxxHaha poor Remi will get to do even more php testing ;)Though to be fair he already does a lot of that with his own repos and multiple php versions there.
Well, the idea is that it will be possible to build the same stack for multiple Fedora releases at the same time and then just pick which stream is the "default" for the release, which will just simply appear to end-users much the same way that it does today as a standard package in an RPM repository.
The modular server release was frankly a disaster... and we all know it.
I suspect you're thinking of the original design which was scrapped. I'm referring to the current approach that we just shipped in Fedora 28 that is purely add-on to the traditional deployment. Please don't confuse the two.
But lessons were learned which is of course important.
Not just learned, but fixes implemented!
I'm honestly not sure how much that will really simplify maintenance of this... or what the path from standard fedora rpm to this would be for someone.
As far as the path from standard RPM to modules, as long as we are mindful of which module stream is default (or explicitly selected), then from an end-user perspective it'll just look like a standard DNF update.
Frankly I fear it'll actually increase my test matrix potentially (standard plus modular) ...
Well, given what I've read in this thread, it seems to me that we can actually reduce your matrix significantly.
1) You wouldn't need "standard" as long as you identified a module stream to be the default for the release. That stream will just show up to DNF as if it was "standard".
2) If both this and PHP use modules, NC can declare that it requires PHP e.g. 8.5 for runtime and it will always stick to that, so you can avoid having to move to a newer PHP base until upstream supports it.
With this in mind, I think it would be a lot easier to maintain it. Then the upgrade instructions would basically become:
```
dnf module enable owncloud:N+1
<run upgrade script>
```
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
