Dropping packages from updates

Hitch

Hitch

Could you please stop dropping packages from updates? I had some issues with one of my systems for work, so I took the time to do a reinstall. To my surprise you’d dropped Chromium from the latest updates, and now I’m left with a system that doesn’t connect properly to web applications for work. I understand the process, but it seems a little better quality control is needed to ensure packages aren’t being dropped. Same happened previously with Tilix, which is now back. If packages are being dropped due to issues, it would be nice to see these in some type of release notes. In the case of Tilix, I understand it was a compiling issue, but folks had to ask in several different places to find out why it was dropped. With the latest, I can’t believe in a couple of weeks something went wrong and it was dropped. It is more likely it was an oversight and not included. Thanks.
 
Hitch said:
It is more likely it was an oversight and not included.
Click to expand...
Certainly not, creation of package repositories is fully automated.

First of all, no matter how much q/a is done, you can't completely avoid build failures. With complex dependency chains, these can possibly affect lots of packages. There are just different ways to deal with them:
  • Create the repository with what succeeded. This is what FreeBSD does.
  • Only create a repository when everything succeeded. I assume NOBODY does that, because then, you'd have a new repository maybe every few months IF you are lucky. (edit1: I DO use this approach for my own repositories built by poudriere, but they only contain a very small subset of packages, so it is kind of feasible here ...)
  • Keep packages from previous builds. This is what some Linux distributions do. It comes with a risk, as there MIGHT be runtime incompatibilities caused by version mismatches, which can lead to all sorts of "weird" behavior.
If you don't like FreeBSD's approach, better complain on the ports mailing list. I personally think from the 3 possible options, it is the sanest choice. If you want to reduce the risk being hit by some missing package occassionally, use quarterly packages. The branch they are built from receives a lot fewer changes, so such problems will occur a lot less often.

edit2: In the vast majority of cases, packages that "went missing" because they or some dependency failed to build already reappear on the next build. "Fallout" mail is automatically sent to the maintainer of a port on any failure on the official builders, which certainly contributes to quick resolutions.
 
zirias@ said:
"Fallout" mail is automatically sent to the maintainer of a port on any failure on the official builders, which certainly contributes to quick resolutions.
Click to expand...
Case in point:
You are receiving this mail as a port that you maintain
is failing to build on the FreeBSD package build server.
Please investigate the failure and submit a PR to fix
build.

Maintainer: sirdice@gmail.com
Log URL: https://pkg-status.freebsd.org/beef...20ea4fbadd_sfd774e065c/logs/fs-uae-3.1.66.log
Build URL: https://pkg-status.freebsd.org/beef...amd64-default&build=p7520ea4fbadd_sfd774e065c
Log:

=>> Building emulators/fs-uae
build started at Sat Jul 1 07:20:27 UTC 2023
port directory: /usr/ports/emulators/fs-uae
package name: fs-uae-3.1.66
building for: FreeBSD main-amd64-default-job-03 14.0-CURRENT FreeBSD 14.0-CURRENT 1400092 amd64
maintained by: sirdice@gmail.com
Makefile ident:
Poudriere version: 3.2.8-23-ga7f8d188
Host OSVERSION: 1400089
Jail OSVERSION: 1400092
Job Id: 03

{..}
Click to expand...
I cut off the entire build log, including the actual error.

So yes, for a brief amount of time the emulator/fs-uae package disappeared from the 14.0-CURRENT repository. I've since submitted a patch to fix the issue. Which has been approved and committed. So now I just have to wait for the build clusters to start a new run and the package will reappear in the repository again.

This is just an example of things that can happen. And it's the port maintainer's job to fix those issues.
 
SirDice said:
This is just an example of things that can happen.
Click to expand...
Adding to that, in an attempt to explain WHY the occassional build error can't be avoided completely: Every port maintainer is expected to do test builds before submitting/committing any change, and as far as I can see, this is done indeed. Still, there are two things:

1.) It's unrealistic to test any combination of
  • All supported FreeBSD releases plus -CURRENT
  • All supported architectures
  • All possible combinations of port options
If you'd do that, with a port with lots of dependencies, you might finish it when upstream already released two newer versions.

What's typically done is pick combinations of FreeBSD version, architecture and default / all-off / all-on options for your tests, which will normally cover 99% of all possible issues.

2.) Build failures can also be caused by other things changing, like in that case, the compiler used in -CURRENT base, but might also be a changed library dependency where some "breaking change" was "hiding well" ... so, in a nutshell, they can occur without any changes to your port.

Therefore, the best thing you can do about that is inform maintainers and rely on their great work to fix things as soon as possible.
 
  • Like
Reactions: mer
pkg upgrade -n
provides a summary of the packages to be installed, upgraded and reinstalled. If something gets removed I think it also says so.
 
mer yes indeed, you can certainly avoid the "surprise" when you just review what pkg wants to do before doing it. IIRC without either -n or -y, it will even ask interactively whether you want to continue as soon as there is some package to be removed.
 
  • Like
Reactions: mer
I've been doing pkg upgrade -n as a standard practice for a while, I like see how disruptive it may be. Check for all the essential packages like X stuff, WindowMaker, gnucash, darktable etc then up arrow backspace y return.

I also am pleased with how quickly a "this doesn't build" gets fixed, especially when we hit quarterlies, pretty impressive for volunteers who usually have a full time job.
 
A package missing in the repository won't remove the locally installed package. It will just show up as 'orphaned' and, obviously, not update it.

Code: 
root@fbsd14:~ # pkg version -vRx fs-uae
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
fs-uae-3.1.66                      ?   orphaned: emulators/fs-uae
Look, it's still missing. That's because my fix was commited to the ports tree when a build was already underway. It will eventually get picked up by the next build run. This is all quite normal.
 
  • Like
Reactions: mer
There is a situation where missing packages can cause installed packages to be removed. If my port had an update (i.e. newer version) and one or more dependencies had updates too, then my installed package might get removed. This is because the dependencies got updated and as a result my package must be updated too. In order to keep the dependency chain correct my package would get removed.

But that will show up in the pkg upgrade output and you get the choice to follow through or not. There's a reason why it asks Proceed with this action? [y/N]:.

This would only show up in certain cases during an upgrade of the installed packages. The OP's issue is that he can't install a certain package in the first place. And there's nothing much to do besides waiting for the issue to get resolved and the package to reappear.
 
  • Like
Reactions: mer
Yes, thanks for further clarifications SirDice. In a nutshell it still boils down to:
- missing packages can happen, the alternatives are IMHO worse, as outlined above
- always review what pkg wants to do before proceeding, to avoid unpleasant surprises
- when doing a fresh installation and a package you want misses, have some patience. Almost always, it's no more than a matter of few days to 2 weeks
 
You must log in or register to reply here.
Back
Top