Re: Math/udunits update

[Brook Milligan <brook%nmsu.edu@localhost>]

> On Mar 6, 2020, at 11:29 AM, Greg Troxel <gdt%lexort.com@localhost> wrote:
> 
> Brook Milligan <brook%nmsu.edu@localhost> writes:
> 
>> [description]
> 
> As I read this, udunits2 is sort of the logical successor to udunits1,
> but it's not clear if they are retroactively renaming udunits to
> udunits-1, as oppposed to it just being version 1.  Actually it feels
> like they are being loose in changing case and putting hyphens in, vs
> having a number in the package name - because they probably don't think
> like we do in terms of naming.

Yes, they are being loose.  The tarballs have no number in the base name, but elsewhere they refer to udunits, udunits-2, and (I think) udunits-1.

Udunits2 is definitely the progression of the development, but there are a couple of potentially breaking changes (see below).

> There's also a question of what the future holds; they seem to have
> broken compat from 1 to 2, and also chosen new names.  So perhaps they
> intend that people can install both.

It looks like both can be installed at once.  I am not seeing any conflicting files.

>> - Make a new udunits2 package and leave udunits as is at v1.
> 
> That seems ok.  It seems that upstream package names really are
> "udunits" and "udunits2", if you judge them by what they put in bin.
> Also we have a "one only, has been one only, and expected to be like
> that always" or "all versioned, even if one this minute" norm, so this
> is off being udunits vs udunits1, but we also avoid renaming.
> 
>> - Update udunits to v2 and abandon udunits v1
> 
> [I split your list because you had three options in 2 bullet points!]
> 
> That seems ok, if the 2 packages that depend on it are ok with that, and
> you expect that in the pkgsrc world nobody else uses that.  If the
> upstream vibe is that udunits2 is the way of the future and 1 is just
> something to migrate away from, this seems like a good plan.

This seems to be the case (see below).

>> - Update udunits to v2 and add udunits1.
> 
> That seems ok, if people need 1; it's basically the same as your first
> option but renaming the old package to 1 so it's clearer.  Hard call on
> what's the least total pain over all people.
> 
>> Given the last statement about grams v. gravity I’m not sure which way to go.  Suggestions welcome.
> 
> What do the upstreams of the depending packages say about which should
> be used?

Upstream says the following:

- udunits1 will not likely have further development, but will remain available for download
- new development will be limited to udunits2
- there is a Fortran API that is limited to udunits1 (I’m not sure if there are plans for a similar API in udunits2)
- the two version differ in their interpretation of “g”, i.e., gravity or grams

Thus, I think we can expect that a udunits(1) upstream would not disappear, although it likely will not change.

> What's driving you to want udunits2?

The specific need is that I need an R package that requires it.

> Do you think there would be any pain if you just update and revbump the
> dependencies?

I’m not sure what this means about whether or not to keep the udunits(1) package versus an upgrade.  If any require the Fortran API, the answer is obvious: keep both.  Likewise for 3rd party users, but I have no idea how to find that out.

I think the safe thing is likely to make a new udunits2 package and leave the other (or rename it, but that causes its own issues as you say).

Thoughts?

Cheers,
Brook