[PROJ] Future maintainance releases

[Greg Troxel]

Kristian Evers <kreve at sdfe.dk> writes:

>> On 30 Oct 2019, at 14:45, Greg Troxel <gdt at lexort.com> wrote:
>> 
>> Bas Couwenberg <sebastic at xs4all.nl> writes:
>> 
>>> [info about proj6 migration status]
>> 
>> From my perspective on packaging many things, proj's trajectory of
>> deprecations is already feeling very rapid compared to how many things
>> depend on it.   Realize that people are still in the process of getting
>> off qt4.
>> 
>> pkgsrc is in a similar position to Debian, although less well baked,
>> with proj6 in wip (sort of like Debian unstable, but not really), and
>> having to define ACCEPT_USE_OF_DEPRECATED_PROJ_API_H to keep some things
>> building.
>> 
>> I don't want to have multiple proj versions in pkgsrc, and I don't want
>> to preclude libosmium, libspatialite, mapnik.
>> 
>> I feel that the "rip the bandaid off" notion is counterproductive, as it
>> really means "break things for users so that packagers have to decide
>> between old proj and dropping dependencies”.
>
> I don’t think that is a fair way to lay it out. From the beginning we've had
> a “double-feature” in the release schedule for the 7.0.0 release with an
> accompanying 6.x-release. This is still the plan and if it turns out to be
> necessary we can put out more releases of the 6.x branch later on. Users
> of proj_api.h should be taken care of for at least a year or two more with
> the 6.3.1 release. But at some point support for 6.x has to stop. I don’t
> want to see us move into Python2 territory!

I think we have some fundamentally different assumptions about things,
both reasonable in their own right, but I'll try to lay out how I think
you see it and then how I do.


I think you are seeing that there are people that are wanting to compile
a single program that depends on proj, and that might or might not use
proj_api.h (meaning that they need proj 6, and 7 will not do).  Then
these people would choose either 6.x (if the program uses proj_api.h) or
7 (if it doesn't), build proj, and then build the program they want to
use.

As I see it, nearly 100% of the uses of any popular program are via some
packaging system.  So users type "pkg_add qgis" (if they are the unusual
ones that use pkgsrc :-), "apt install qgis" (ish), or something that
amounts to the same thing.  This gets them -- as an automatic dependency
--the proj version chosen by the people curating the packaging system --
which is people like Bas and me.  Most users don't know how to build
things; they rely on binary packages prepared by packaging systems.

Packagers have a big first choice: does the packaging system use a
single version of proj, or does it have some scheme to have multiple
versions and somehow namespace them to permit simultaneous use.

If a single, then do we choose 6.x, and leave out features, or do we
choose 7.x and *entirely drop* packages that still use proj_api in their
*latest formal release* from the packaging system?

If we go down the multiple path, then how do we organize things where
(making things up) qgis depends on proj and can use 7, but qgis depends
on libspatialite which needs proj_api and thus 6.  But any one program
can only link one proj.  Plus, multiple parallel-installable versions is
hard, and in pkgsrc we use that mostly for things like python.

Right now, pkgsrc is not even updating to proj 6, but has it in a
staging area.  Probably it's about time to really update.  Debian is in
process -- I just read that it's in unstable but not yet in a formal
release.  This delay in moving both pkgsrc and Debian from 5 to 6 is
already gated by compatibility issues; if every program that compiled
with 5 built with 6, it would have just been updated quickly, with no
wailing and gnashing of teeth.

That's a long way of saying that "users can just use 6 if they need to"
doesn't fit with the my notion of how users rely on a collection of
binary packages.  Hence that releasing 7 with an API break leaves
packagers with the choice of "don't give 7 to users" vs "drop things
that don't build with 7"


All of this leads to the issue of "but things have been deprecated for a
wicked long time (as we say in Boston)".  Unquestionably true.  But I
have seen over the years that when a package is foundational and very
widely used, that API withdrawals take a very long time to completely
ripple through the ecosystem.  In pkgsrc we are just dealing with
removing qt4 (and Debian is only a few steps ahead of us, struggling
with exactly the same issues).  Programs from high-functioning upstreams
with regular release like GNU Radio have made releases as recent as
April 2019 which use qt4, even though the last release of qt4 was in
April of 2015, and it went EOL at the end of 2015.


I'm not trying to say specifically what you should do.  Just that when
there is a new release with an API withdrawal, then packagers have to
choose between not updating and dropping things that don't build or
can't easily be patched to build.   If the notion is that 7 will be
released but you don't expect packaging systems to adopt it, that's
perhaps an interesting situation that I haven't really pondered.

(speaking only for me, of course)

Greg