Re: Removal of firefox115 and firefox128

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

"David H. Gutteridge" <david%gutteridge.ca@localhost> writes:

> My other issue is I'm not entirely comfortable with the pkgsrc
> approach of leaving in EOL packages that probably (or knowably)
> have security issues. I know there's the whole "let the users
> decide" philosophy.

It's been a steady principle of pkgsrc to package things that somebody
might to want to run.  Withdrawing packages and making life difficult
because somebody thinks somebody else shouldn't run it is not
reasonable, and approaches nanny state (except that we'd be saying "we
won't help you", not "we'll use force to stop you").  Instead, pkgsrc's
removal process has historically been about one of

  - we believe there are essentially zero users

  - we believe that almost anyone using P version V should be moving to
    at least V+1 or package P', and we can confidently tell any V user
    they should update, *without knowing anything about their situation*

  - the package is broken and it is clear that no one wishes to spend
    time fixing it -- so it doesn't matter how many users there are, and
    keeping it is just a waste of build resources and a source of
    pkg-bulk failure noise

To me, the real point is that everybody has their reasons to run or not
run each piece software; whether it's EOL or whether there are known
issues are just two of many things that might cause them to decide.  And
that it's somewhere between difficult and impossible for someone else to
make that decision for someone else -- even with a full awareness of
their situation.  Without a deep awareness of their world, it isn't even
plausible.

(As I know you know, but for completeness), we already have two
mechanisms to address the "package is EOL upstream":

   - adding an eol pseudo-vulnerability to the database
   - noting in DESCR that the package is no longer maintained upstream

I have been trying to note such things in DESCR, partly as notes to
future self.

People who want to avoid eol known security issues at all costs can just do

  # Make a really good backup, a 2nd and a 3rd, because I believe
  # *everyone* who runs this is going to want to restore!
  # Not tested!
  false && audit-packages | awk '{print $2}' | while read p; do pkg_delete -r $p; done

I suspect there are zero people on this list who are really using pkgsrc
and have empty audit-packages output.

And of course people can run audit-packges and make their own decisions
package by package.  Or they can decide not to run audit-packages at
all.  Just like they can choose to plug in to the mains devices that
aren't listed by a Nationally Recognized Testing Lab, or to charge an
ebike inside, but I see your point that us not withdrawing a package is
different, and a choice on our part.

(I suspect a lot of things that audit-packages prints have been fixed
but the package pattern hasn't been updated.  That's mostly orthogonal
to this discussion, but a clue about how much people really care about
this.)



All things considered, removing 115 seems fine as "it is broken and
nobody is willing to fix", with the last successful build in June which
was 2025Q1.  But with someone willing to address problems in 128 that
are likely to occur, it seems that should stay.  Checking bulktracker,
it is currently building on NetBSD 9/10/11 on amd64 and 10/11 on
aarch64.  Which is pretty good for a browser.


There's another question that you didn't really address explicitly, but
about which I think you are steering correctly.  When packages that are
EOL or very-old-LTS depend on difficult packages (unstable interfaces,
like rust, mostly, and I would put llvm in this category, relative to
packages that deeply depend on it), then it isn't reasonable to demand
that any update to those packages be held until the EOL package is fixed
up.  To me where to draw the line on "is it ok to update [rust|llvm|?]
if it breaks e.g. firefox-old" is the hard question.   And I agree that
breaking firefox115 is ok.