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 10:44:26AM -0500, Greg Troxel wrote:
>> 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 wouldn't.

I am not following.  My point is that we have old versions around for
multiple reasons, and a big one is that the newer version, that in
theory someone ought to run, doesn't work on their platform.  This is
different by some combination of os/version/cpu.   So I don't see how
there can be a single "esr" that is always going to be available.

> 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.

> I don't think that there should be a possibility to install Firefox 52
> by accident when you're expecting the latest, supported ESR release.
> It's a security nightmare.

I don't understand this comment at all.

> I've been making sure the latest stable branch gets backports when the
> latest ESR version gets a new release - I don't do it for any others.

If some versions get security fixes and some don't, it would be great to
have this clearly explained in DESCR.

> Currently that is firefox68, which is still receiving security updates
> from upstream.

I see that firefox is already not following our all-versioned norm.

> You also need to transfer profiles when there's a change in the version
> right now. That's not obvious to do with Firefox's UI (you have to go to
> some about: page) and is very annoying for the main use case of ESR -
> having a more conservative branch of Firefox where you stay on the latest
> version to continue getting security patches without any other stuff.

I am again not following.  Are you saying that changing the PKGPATH
and/or PKGNAME would change this behavior?

> Presumably this makes it more difficult to use pkgsrc ESR in enterprise
> deployments where lots of installations are managed centrally, which is
> ESR's reason for existing. No other vendor does it the way we do for
> good reasons.

I again don't follow why our choice of PKGPATH or PKGNAME has anything
to do with these problems.