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

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

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

> On Tue, Dec 17, 2019 at 12:46:39PM -0500, Greg Troxel wrote:
>> > The idea is that the latest ESR release should always be
>> > firefox-esr, while any versions that we're keeping around that are no
>> > longer supported upstream can retain the version suffix. Basically,
>> > that means firefox52.
>> 
>> This ignores the notion of the norm for always versioned or never
>> versioned.
>
> The norm was established for programming languages and server software that
> has support cycles lasting years, e.g. Python 3.6 will be supported until 2021
> while 3.7 and 3.8 are also supported.

That's partially/mostly true, but it is also for things that have
upstreams that release versions such that people want to run the old
ones, even if upstream doesn't really appreciate that.

> Firefox doesn't operate in the same way.
> The FF major version is bumped every few weeks or months and the previous version
> is immediately unsupported. That applies to Mozilla's "Standard" and "Extended
> Support Release" branches.

We have multiple things with unsupported old versions.  That's basically
life on !Linux, where upstreams have breaking changes for systems they
don't test on.

> Versions that aren't the currently supported ESR are only kept long term
> in exceptional circumstances (e.g. the switch of programming language),
> because their use is an actual security problem.

The security issue is true of most old versions in pkgsrc, but yes,
firefox is more acute.

> Even then, are `nginx` and `nginx-devel` always-or-never-versioned?
> Two concurrent branches with upstream support...

I guess that's another case.  But there isn't renaming churn with that;
each tracks something, and acts like a single package.  Renaming is the
basic problem.

I should say that having a single firefox and a single firefox-ESR
doesn't bother me at all.  My problem is that it seems that firefox is
something that we need N versions of, for N-1 reasons.  Currently N is
4.

> On Tue, Dec 17, 2019 at 12:46:39PM -0500, Greg Troxel wrote:
>> I again don't follow why our choice of PKGPATH or PKGNAME has anything
>> to do with these problems.
>
> 'pkgin upgrade' doesn't work. At all. You get stuck with an insecure,
> unsupported release until you explicitly do:
>
> `pkgin remove firefox60`
> `pkgin install firefox68`
>
> Then migrate your profile. 

You didn't explain about profile migration.  What is the cause of
profile migration being necessary?

  Is it because the package was remove/install rather than pkg_add -u?

  Is it because PKGPATH is different?

  Is it because PKGNAME is different?

  Is it because the binary is called firefoxNN instead of firefox, or
  some similar "configure this firefox as foo" logic?


I would also like to understand how often we need multiple versions
(other than current release and ESR - I get that).  Right now also we
have

  52: because upstream chose a nonportable language

  60: an old ESR, and I have no idea why

Do we need 60 because people need it for sites that fail with 68, as
Manuel hints?  Or maybe we don't need it.


Is the next ESR soon?  Are you suggesting that when that happens we add
firefox-ESR as that release?  Or something else?