Dear all,

The latest version of NatTable (2.0.0) depends on Eclipse Collections (https://www.eclipse.org/collections/).
Originally, it was called GS Collections, and was renamed when it
migrated to the Eclipse Foundation.
GS Collections is present in Debian (as gs-collections: https://tracker.debian.org/pkg/gs-collections), but not Eclipse Collections.

Should we package Eclipse Collections as a separate project (in which
case I will submit an ITP bug), or update and rename the existing package?
For your information, the package gs-collections has no reverse
dependency and has not been updated since September 2017.

Best wishes for the new year
Vincent

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Vincent,

On Thu, Jan 07, 2021 at 01:56:41AM +0100, Vincent Prat wrote:

Dear all,

The latest version of NatTable (2.0.0) depends on Eclipse Collections (https://www.eclipse.org/collections/).
Originally, it was called GS Collections, and was renamed when it
migrated to the Eclipse Foundation.
GS Collections is present in Debian (as gs-collections: https://tracker.debian.org/pkg/gs-collections), but not Eclipse Collections.

Should we package Eclipse Collections as a separate project (in which
case I will submit an ITP bug), or update and rename the existing package? For your information, the package gs-collections has no reverse
dependency and has not been updated since September 2017.

I see either choice as acceptable, but my suggestion is to update
the existing package (and rename it only if you think it is necessary).
It is the evolution of (and thus an update to) gs-collections. This
approach means you don't have to go through NEW, we don't have to
introduce a new package to archive, and developers who know the software
by gs-collections will still find it. Even if there aren't r-deps in
Debian, perhaps a downstream is using gs-collections and will benefit
from the update without a rename.

If you decide to create a new source package for eclipse-collections,
please also take the time to RM gs-collections. We don't need to keep
the old package around if we have a compatible replacement. (I'm
assuming that eclipse-collections is a drop-in replacement, or nearly so
- maybe just a Java package name change?)

Best wishes for the new year

Same to you!

Cheers,
tony

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAl/3JeIACgkQIdIFiZdL Ppa7ShAArXmZMrlHmhXwBJT30vlZu1+KAtRzZdiuDt0mfYYTH91fBGcMzUyyiD/L ZQ9do46M9qd3DK6IAEkGDo7xtBAD9CUdriWxJZ1DYJYqtIOzMpiKNtvmB/4eTeux mNsEfe6tJsBMoTIwi6WXM0kwUdOyjkpAyo9i9IX70sFL7TBfRipjlIeLZx2n+jKL sBg8KK1t0iOtDe5/Bebj3X5aqRMSvxRMAYR/2Mxd+sfArDrStb23Enz8tJbyDDse bk+6pfxWSJAwGZL927Sy9jV5I14+L6R8ezjWz+pOMfptFUE0/WssjmF5vtnPeeUx ImLOtuCEF29AFbNT7UqY2LzncwXz021aqxkyCCII5uC9T8MqJ77l00Uli9NW2sQ9 llUq2g4pngI/yCaS7RyLPUecJS4yvuo3Q8Ma5cXBfXVVZ4zC/FwaUlcvQ/0ugi+S dwTPN7c8QFQjU78NOT0yOuzs2BasCfvnMzzLuGxWN0AcsaW6XeSGbQoGBrcjL/uq UU0EsqfEImA+cW1INquzqKb1gQ7RDHd5MYxqGeeCflKxJGZWp3MF2vwoYDydrTHM hnEvRDgItXrbb5FMxqLmO5QMW0KQ1NS32Vd1TX8HFQS5rBTxcsraJBoD9JaM0zp/ 2RBNs37L75HFa1UnfBGuSw/s2D5h5TFyQTceIr7p0L804cf5AcA=
=MgP4
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Tony,

Should we package Eclipse Collections as a separate project (in which
case I will submit an ITP bug), or update and rename the existing package? >> For your information, the package gs-collections has no reverse
dependency and has not been updated since September 2017.

I see either choice as acceptable, but my suggestion is to update
the existing package (and rename it only if you think it is necessary).
It is the evolution of (and thus an update to) gs-collections. This
approach means you don't have to go through NEW, we don't have to
introduce a new package to archive, and developers who know the software
by gs-collections will still find it. Even if there aren't r-deps in
Debian, perhaps a downstream is using gs-collections and will benefit
from the update without a rename.

What about developers who do not know the software and need Eclipse Collections?
Do they have to guess that the Java package is provided by the Debian
package gs-collections?
Eclipse Collections is indeed the evolution of GS Collections, but the
latter still exists as such, even though only bug fixes are made.
By the way, the version present in Debian is out-of-date.

If you decide to create a new source package for eclipse-collections,
please also take the time to RM gs-collections. We don't need to keep
the old package around if we have a compatible replacement. (I'm
assuming that eclipse-collections is a drop-in replacement, or nearly so
- maybe just a Java package name change?)

Yes, the Java package name is different. So, even if the API is
compatible, this would require downstream to change imports, classpaths,
etc.

In any case, since Emmanuel Bourg was the one who packaged
gs-collections in the first place, it would be nice to have his opinion
on the question.

Cheers,
Vincent

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Jan 07, 2021 at 07:10:25PM +0100, Vincent Prat wrote:

Hi Tony,

Should we package Eclipse Collections as a separate project (in which
case I will submit an ITP bug), or update and rename the existing package? >> For your information, the package gs-collections has no reverse
dependency and has not been updated since September 2017.

I see either choice as acceptable, but my suggestion is to update
the existing package (and rename it only if you think it is necessary).
It is the evolution of (and thus an update to) gs-collections. This approach means you don't have to go through NEW, we don't have to
introduce a new package to archive, and developers who know the software
by gs-collections will still find it. Even if there aren't r-deps in Debian, perhaps a downstream is using gs-collections and will benefit
from the update without a rename.

What about developers who do not know the software and need Eclipse Collections?
Do they have to guess that the Java package is provided by the Debian
package gs-collections?

Yes, this happens all of the time already.

Eclipse Collections is indeed the evolution of GS Collections, but the
latter still exists as such, even though only bug fixes are made.
By the way, the version present in Debian is out-of-date.

If you decide to create a new source package for eclipse-collections, please also take the time to RM gs-collections. We don't need to keep
the old package around if we have a compatible replacement. (I'm
assuming that eclipse-collections is a drop-in replacement, or nearly so
- maybe just a Java package name change?)

Yes, the Java package name is different. So, even if the API is
compatible, this would require downstream to change imports, classpaths,
etc.

It sounds you're making the case for having both packages within
Debian?!?

In any case, since Emmanuel Bourg was the one who packaged
gs-collections in the first place, it would be nice to have his
opinion on the question.

Sure. I won't comment further.

tony

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAl/3aEkACgkQIdIFiZdL PpbbZBAA1G2axMcOmAhZHIrr8i8XdATn3naSDlOyf+0iLEuZA1yfzIfR9nNeJipM ne5j6Vd7H6IOQodoQMWg48okdxMN73+cmUWHT3PHvsOiSou+k2dPP2zMMajyNE2g 1Kz9qTdO6gUo7FHH70ExlK+fX4y5XhEmxxxIYexmoNmuNOkcyovcjz9s7yMbLax+ dhEgEt7DMn3pnxRqYLHGc7sbQZM/bNmllmFzfSEpvScKi2eBRxKaY6k/+fvjINe9 UabBn8LcCFI7b0Po22gWDUErzopwuGD6q7K+PtlU9gLQLHCx2T5JJNOW136sVa1A zBXt4GUP0gnmPfKjySvRzpVVw+VSJQltHaW2Bk10SEzlezvQ6uz9kHcdAYHDgSYG kunjDZm28fDLY/7a83Pr4vLB2LLx+Z2YQlHwSWHALXlDiakclLtH5qSDTnQ73sNb oyMEd+gLgiwTymyBnuDGTcgAD+W3soDbv20W651C0rBNywAogzQAAVd4MYGeICRB 6z7pMSXCyLLlFng2Izd+9xq5Ff5pBRutcW8UewNDKdpNLsr6M4oI/BvkBQAEteXr dv4hRVvkKyI8GQlcfRz8tqQnHd0V1AXT0q3Fdazq4hx5ntQBl6Q25TslWViMBNbu 037KVd2Rl0Yk2Mjb6Wf2wGK2B9hKB6NChJlXqZBRzXSHHaoCfu4=
=6WUl
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Vincent,

libgs-collections-java is still used to build libreactor-core-java.

eclipse-collections is incompatible with gs-collections because the
package name was changed to org.eclipse.collections.

For these reasons I suggest to keep the gs-collections package for now,
and create a new eclipse-collections source package building libeclipse-collections-java. The gs-collections repository on Salsa can
be cloned and used as a starting point for the new package.

Emmanuel Bourg


Le 07/01/2021 à 01:56, Vincent Prat a écrit :

Dear all,

The latest version of NatTable (2.0.0) depends on Eclipse Collections (https://www.eclipse.org/collections/).
Originally, it was called GS Collections, and was renamed when it
migrated to the Eclipse Foundation.
GS Collections is present in Debian (as gs-collections: https://tracker.debian.org/pkg/gs-collections), but not Eclipse Collections.

Should we package Eclipse Collections as a separate project (in which
case I will submit an ITP bug), or update and rename the existing package? For your information, the package gs-collections has no reverse
dependency and has not been updated since September 2017.

Best wishes for the new year
Vincent

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)