[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: www/firefox-esr instead of www/firefox[0-9]*
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
> 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.
Main Index |
Thread Index |