Re: www/firefox-esr instead of www/firefox[0-9]*

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

nia <nia%NetBSD.org@localhost> writes:

> I think the package for the latest ESR release of Firefox should always
> be named "firefox-esr", for the following reasons:
>
> - Easy binary upgrades.
> - No need to update e.g. bulk build limited lists when a new version
>   is released.
> - Less surprising for users (other vendors usually use the firefox-esr
>   name).
>
> I understand we currently have more than two versions in tree -
> I don't think there's any problem with naming older legacy versions
> using the numbers scheme.
>
> Is the multiple versions thing the only reason we're not doing this
> already? I don't really understand this.

We have a general notion about versioned names, which is that each
package should either be

  U) unversioned, and (always) there is one, and (mostly) this has been
  true for years, and (very much so) is expected to be true indefinitely

  V) versioned, and all packages in the tree are versioned.  There can
  be only one at times, but basically the idea is that the criteria in U
  are not met.

A lot of the point is to avoid churn; we should not be moving packages
between U and V frequently.  Transition to V often just has to happen,
and thus there is a notion of being very slow to move to U.  Part of
that is that an upstream that required V cannot be relied on to support
the U situation in the future.

The tree does not entirely follow these guidelines now, but generally
changes to the tree have not been making noncompliance greater.

I don't have a problem with "firefox-esr" being a package name, but if
there are multiple esr versions, then they should be versioned.

The root cause of the larger problem is upstreams (of language
specifications, compilers, and individual packages) making changes so
that "just use the latest release" does not lead to good outcomes.  If
there are multiple esr versions of firefox, that's a clue that firefox
is one of those upstreams :-) But with rust and old systems, it seems
pretty clear that the entire firefox world is a "we need to keep
multiple around".

I don't understand how a single esr name would work.  What happens on
older platforms where that single one doesn't build, and people want the
previous esr?  If they are running an unversioned package, then they
will have no package available, instead of getting an update to the one
they are running.

It seems that when we have old firefox, then people generally want to
most recent one that works on their system.  And perhaps to stay on one
that hasn't deprecated an interface needed by a plugin they want.  But
some people also want to choose to jump branches when they have time,
not automatically.

Overall, I don't have a problem with users having to choose to jump
versions.  I see that discomfort as minor compared to the confusion and
churn caused by mixing versioned and unversioned names and going back
and forth.


It could be that pkgin or similar could have support for "choose latest
firefox esr" and some pkgsrc-wide metadata about recommended version of
that, which is somehow aware of OS version/cpu/etc. in that choice.

Overall, I don't think we should depart from the versioning norms above.