Re: CVS commit: [pkgsrc-2023Q2] pkgsrc/www/php-nextcloud

[Greg Troxel <gdt%lexort.com@localhost>]

> The upstream has no problem at all.

I don't think that's fair.  It is unreasonable to need to install every
major version; upgrades should be supported across some reasonable
interval.  How can this possible work with say Debian or Ubuntu?  Their
releases (if you count Ubuntu LTS as Ubuntu) are every 2 years or so.

Many programs with databases have upgrade scripts from x to x+1, and if
you have to go from say 21 to 26, it just applies 5 in a row in a
transaction or something.

But this is pkgsrc, and upstream is how it is.  We can't fix upstream
nextcloud, so I'm only going to talk about how to deal with it.

> Last some months, I cannot find a time to update www/php-nextcloud
> package.

That's fine; I did not mean to complain *at all* that it wasn't updated.
25 is running perfectly ok for me.  It can store files and do
caldav/carddav, which is all I need.

release dates since I am unclear on the schedule:

25 2022-10-19
26 2023-03-21
27 2023-06-13

> I should update www/php-nextcloud to 26 before pkgsrc-2023Q2 branch.

I'm not sure I follow, but I interpret this as "each branch should
include the current version of nextcloud".

> And I want to include 27 for next pkgsrc-2022Q3 branch.
> So pkgsrc-2023Q2 should have 26.

Except that it didn't, and as a matter of policy we do not pull up
changes to stable branches other than security or build fixes, except in
truly exceptional circumstances.

In this case, I'm not sure how many people are using it, and running a
nextcloud instance is something that requires some active sysadmin work
anyway.  I can certainly cope myself, but I don't think I'm typical.

There's another problem, which is that I updated  along the branch and
rebuilt and did 'pkgin fug' from that binary set, and got an error
message that "this version of nextcloud requires php8".  But my package
was

  php74-nextcloud-26.0.4.tgz

I rolled back and my installation is ok.  So it seems that there is a
missing change in the php requirements.

Again I can cope, but this is further difficulty for those on the stable
branch that expect a stable experience and basically zero-risk upgrades.


I'm really not sure what we should do.   I can think of three things to
do

CHOICE 1

My immediate reaction is that we could

  - revert the pullup because (regardless of desires for sequencing
    future upgrades) it causes trouble for those on the stable branch.

  - fix the php version declarations on pkgsrc-current so that 26 on
    current is sound (I think it is just adding 7x to
    PHP_VERSIONS_INCOMPATIBLE

and then we should step back and assess what to do.

One thought is to keep multiple versions of nextcloud in pkgsrc at all
times, because it's so difficult to deal with updating.  At one point
years ago I was multiple versions behind and I had to cvs up -D multiple
times to build and run intermediate versions.  Again, I can do that, but
it was trickier than it should have been (due to the upstream bug of
single-version upgrades -- not your fault!!).

So, we would, after the above two steps:

  copy php-nextcloud to php-nextcloud26

  upgrade php-nextcloud to 27

and in general, whenever upgrading, just copy to nextcloudNN.

Then, we can delete them after some time, maybe 1 year after the
upgrade.  Then, anyone with a stable branch package set can install
their old one if they don't want to upgrade, and install the next one
when they want to.  Generally people should upgrade and stay current of
course.  But it would decouple nextcloud upgrades in pkgsrc from branch
cycles and when users have to update.

CHOICE 2

Fix the php version in pkgsrc-current, and pull that up.  Force any
users on the stable branch to not only do the nextcloud upgrade, but if
they are running php7x to change to php8.  This is unattractive because
having to change php versions mid-brach is far beyond expectations.

CHOICE 3

Like choice 1, revert the change on the branch and fix pkgsrc-current
php version requirement.

Leave 26 in pkgsrc-current and let it be 2023Q3.  Then, as soon as
2023Q3 is cut, upgrade to 27, so that is in 2023Q4.  Every quarter,
update one version.

This is ok in that the branch experience is stable, but it is behind.


Overall, I think choice 1 is the right approach, because while there is
a small amount of work, copying a package and applying CONFLICTS to
them, I expect that is very quick.  Then, this entire sequencing problem
is no longer a problem (except that users have to "pkgin install" the
right version, but that's pretty easy).

If we pick choice 1, then those copied packages could get upgraded for
security releases, or they could not.  The DESCR could say that they are
not maintained and should be used only for updating.

I could do the creation of the old version 26, if that would help with
time.   I very much appreciate you maintaining nextcloud.

What do you think?