etesync-dav upgrade to 0.18.1, new package radicale3 #22810

ProjectMoon · 2020-06-11T19:38:20Z

This upgrades etesync-dav to 0.18.1, which requires radicale 3.x. So there's also a commit adding radicale3, and making it conflict with radicale and radicale2.

ProjectMoon · 2020-07-04T12:16:08Z

Rebased to the latest master.

Piraty · 2020-07-05T18:29:16Z

I am not sure about how the conflicts= logic works.

does the mechanism require all packages to explicitly list all of the others in order to work correctly (@Duncaen ?)
in that case, you should revbump the old packages so the binary packages are updated

ProjectMoon · 2020-07-06T14:46:05Z

It might make sense to revbump yes. It's definitely safer if nothing else.

CameronNemo · 2020-07-18T00:04:17Z

Why keep radicale2? The only reason we kept radicale 1 was so that old data could be migrated to version 2. But version 3 only changes a few config keys, it does not change the data format.

srcpkgs/radicale3/INSTALL.msg

ProjectMoon · 2020-07-22T20:35:32Z

Some rather major changes to this PR, based on the suggestions of @ahesford:

The radicale3 package was removed, and instead the radicale package now has radicale3.
The radicale2 package has been turned into a transitional package pointing to radicale.
Essentially, we are dropping radicale2, and using the original package to upgrade to the latest version of Radicale.
Configs for Radicale placed in /usr/share/examples in case of upgrade from old versions when /etc/radicale is not touched.
Updated INSTALL.msg for Radicale.

etesync-dav upgraded to 0.20.0, and depends on the upgraded radicale package.

ericonr · 2020-07-22T20:39:30Z

srcpkgs/radicale/INSTALL.msg

+package. To remove radicale2 and transition to the radicale package:

-If you need to migrate data, take the following steps:
+    xbps-pkgdb -m manual radicale
+    xbps-remove radicale2


I don't think this last part is necessary. Having a dummy package around isn't an issue.

Not an issue per se, no. But it makes the system cleaner.

Yes, but it also makes an already long INSTALL.msg even longer.

This install msg needs to be huge, I don't think we should make it bigger for something that brings little value. People who care about the amount of packages they have know how to fix this.

This whole INSTALL.msg should be gutted. The last version of radicale v1 is three years old. We should not try to hold users' hands by dumping long instructions that are unlikely to be read anyway. The entire contents of this file should be eliminated and replaced with this simple message:

CAUTION: Radicale 3.x is not backwards compatible with Radicale 1.x. If you are upgrading from Radicale 1.x, please consult upstream documentation for information about migrating existing data to the format used by this version.

Note that https://radicale.org/1to2 now returns 404, so even Radicale is not interested in helping users migrate from a long-dead version. This is not our problem to solve. If somebody is interested enough, the information can be found in the Wayback Machine.

srcpkgs/radicale/template

ericonr · 2020-07-22T20:42:22Z

srcpkgs/radicale/template

 	vinstall radicale.fcgi 644 usr/share/radicale
 	vinstall radicale.wsgi 644 usr/share/radicale
 	vsv radicale
 }
+
+radicale2_package() {
+	depends="radicale"


You might need something like radicale>=3, not sure.

depends="${sourcepkg}>=${version}_${revision}"

srcpkgs/radicale3/template

ericonr · 2020-07-22T20:44:54Z

Also the commit message is wrong.

ericonr · 2020-07-22T20:58:27Z

srcpkgs/radicale/template

-
+distfiles="https://github.com/Kozea/Radicale/archive/${version}.tar.gz"
+checksum=9e22273dda13938b44e0555a96f63e0491e42c1e58a290864ecae1181580be8c
+provides="radicale-${version}_${revision}"


It shouldn't need provides any more.

ericonr · 2020-07-22T21:00:26Z

srcpkgs/radicale/INSTALL.msg

+Migration from version 1.x to 2.x and beyond is not backwards
+compatible. Migration of data from 2.x to 3.x is not necessary. If you
+need to migrate data from 1.x to 2.x, take the following steps:


The migration instructions need to be updated as well.

See prior comment about dropping all of this text in favor of a simple message noting the incompatibility.

ahesford · 2020-07-23T02:20:08Z

srcpkgs/radicale/template

 short_desc="Complete calendar and contact storing and manipulating solution"
-maintainer="lemmi <lemmi@nerd2nerd.org>"
+maintainer="projectmoon <projectmoon@agnos.is>"


Did @lemmi ask you to take over this template?

No. This was copied from the template for radicale3. Do you want me to change the maintainer back?

Just saw his comment.

ahesford · 2020-07-23T02:22:17Z

srcpkgs/radicale/template

 	vinstall radicale.fcgi 644 usr/share/radicale
 	vinstall radicale.wsgi 644 usr/share/radicale
 	vsv radicale
 }
+
+radicale2_package() {
+	depends="radicale"


depends="${sourcepkg}>=${version}_${revision}"

ahesford · 2020-07-23T02:31:23Z

srcpkgs/radicale/INSTALL.msg

+package. To remove radicale2 and transition to the radicale package:

-If you need to migrate data, take the following steps:
+    xbps-pkgdb -m manual radicale
+    xbps-remove radicale2


This whole INSTALL.msg should be gutted. The last version of radicale v1 is three years old. We should not try to hold users' hands by dumping long instructions that are unlikely to be read anyway. The entire contents of this file should be eliminated and replaced with this simple message:

CAUTION: Radicale 3.x is not backwards compatible with Radicale 1.x. If you are upgrading from Radicale 1.x, please consult upstream documentation for information about migrating existing data to the format used by this version.

Note that https://radicale.org/1to2 now returns 404, so even Radicale is not interested in helping users migrate from a long-dead version. This is not our problem to solve. If somebody is interested enough, the information can be found in the Wayback Machine.

ahesford · 2020-07-23T02:32:07Z

srcpkgs/radicale/INSTALL.msg

+Migration from version 1.x to 2.x and beyond is not backwards
+compatible. Migration of data from 2.x to 3.x is not necessary. If you
+need to migrate data from 1.x to 2.x, take the following steps:


See prior comment about dropping all of this text in favor of a simple message noting the incompatibility.

lemmi · 2020-07-23T06:38:15Z

@ProjectMoon thanks for stepping up, just my 2 cents:
I don't have the capacity to maintain any of the newer radicale variants and I'm still running radicale 1, so I propose this:
We rename radicale to radicale1 and make radicale the package that tracks the newest radicale 3 release. Should I finally be able to also make the transition, I'll deprecate radicale1.

ProjectMoon · 2020-07-23T08:47:23Z

@ProjectMoon thanks for stepping up, just my 2 cents:
I don't have the capacity to maintain any of the newer radicale variants and I'm still running radicale 1, so I propose this:
We rename radicale to radicale1 and make radicale the package that tracks the newest radicale 3 release. Should I finally be able to also make the transition, I'll deprecate radicale1.

This sounds good, but then we need to make a breaking change to the package tree, right?

ahesford · 2020-07-23T14:08:25Z

I'm not crazy about splitting to radicale1 and updating radicale to v3. It's not much better than making radicale3. An inability to upgrade from the old radicale package sounds like an argument for holding local package versions, rather than altering the package tree to accomodate outdated software.

Maybe the INSTALL.msg for an updated radicale could include some basic instructions for reverting to an old version if that is required by some users:

CAUTION: Radicale 3.x is not backwards compatible with Radicale 1.x. If you are upgrading from Radicale 1.x, please consult upstream documentation for information about migrating existing data to the format used by this version.

If you are unable to upgrade but require Radicale 1.x to function, you can install the xtools package and run

	xdowngrade /var/cache/xbps/radicale-<version>.<arch>.xbps
	xbps-pkgdb -m hold radicale

for your architecture and locally cached version number.

If you do not have a cached version of the package, you can install an unmanaged version with, for example

	pip install radicale<2

You may wish to use a virtual environment to isolate pip-installed packages from system-managed packages.

CameronNemo · 2020-07-23T15:50:19Z

@lemmi perhaps you can hold the radicale package for updates, seeing as the 1.x branch is not and probably will not receive any updates moving forward?

ProjectMoon · 2020-07-28T18:55:27Z

Due to branch reorganization, GitHub closed this PR. New PR at: #23908

ProjectMoon force-pushed the master branch from 2f13639 to 657a4a5 Compare June 11, 2020 19:55

ProjectMoon force-pushed the master branch 2 times, most recently from c4d6f5d to f0aa00c Compare June 27, 2020 13:23

ProjectMoon force-pushed the master branch from f0aa00c to ca979d1 Compare July 4, 2020 12:15

CameronNemo reviewed Jul 18, 2020

View reviewed changes

srcpkgs/radicale3/INSTALL.msg Outdated Show resolved Hide resolved

ProjectMoon force-pushed the master branch from ca979d1 to 1ac9578 Compare July 22, 2020 20:31

ericonr reviewed Jul 22, 2020

View reviewed changes

ProjectMoon force-pushed the master branch from 1ac9578 to 09d3d0c Compare July 22, 2020 20:55

ericonr reviewed Jul 22, 2020

View reviewed changes

ahesford requested changes Jul 23, 2020

View reviewed changes

ProjectMoon closed this Jul 28, 2020

ProjectMoon force-pushed the master branch from 09d3d0c to 67cd5c3 Compare July 28, 2020 18:48

ProjectMoon mentioned this pull request Jul 28, 2020

Etesync dav 0.20.0 #23908

Closed

github-actions bot locked as resolved and limited conversation to collaborators Aug 17, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

etesync-dav upgrade to 0.18.1, new package radicale3 #22810

etesync-dav upgrade to 0.18.1, new package radicale3 #22810

ProjectMoon commented Jun 11, 2020

ProjectMoon commented Jul 4, 2020

Piraty commented Jul 5, 2020

ProjectMoon commented Jul 6, 2020

CameronNemo commented Jul 18, 2020 •

edited

ProjectMoon commented Jul 22, 2020

ericonr Jul 22, 2020

ProjectMoon Jul 22, 2020

ericonr Jul 22, 2020

ericonr Jul 22, 2020

ahesford Jul 23, 2020

ericonr Jul 22, 2020

ahesford Jul 23, 2020

ericonr commented Jul 22, 2020

ericonr Jul 22, 2020

ericonr Jul 22, 2020

ahesford Jul 23, 2020

ahesford Jul 23, 2020

ProjectMoon Jul 23, 2020

ProjectMoon Jul 23, 2020

ahesford Jul 23, 2020

ahesford Jul 23, 2020

ahesford Jul 23, 2020

lemmi commented Jul 23, 2020

ProjectMoon commented Jul 23, 2020

ahesford commented Jul 23, 2020

CameronNemo commented Jul 23, 2020

ProjectMoon commented Jul 28, 2020

etesync-dav upgrade to 0.18.1, new package radicale3 #22810

etesync-dav upgrade to 0.18.1, new package radicale3 #22810

Conversation

ProjectMoon commented Jun 11, 2020

ProjectMoon commented Jul 4, 2020

Piraty commented Jul 5, 2020

ProjectMoon commented Jul 6, 2020

CameronNemo commented Jul 18, 2020 • edited

ProjectMoon commented Jul 22, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ericonr commented Jul 22, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lemmi commented Jul 23, 2020

ProjectMoon commented Jul 23, 2020

ahesford commented Jul 23, 2020

CameronNemo commented Jul 23, 2020

ProjectMoon commented Jul 28, 2020

CameronNemo commented Jul 18, 2020 •

edited