Where are some packages?

Hello.

When I try to install packages, I don't see some of them. What do I wrong?

Code:
root@temp:/ # uname -a
FreeBSD temp 14.0-RELEASE FreeBSD 14.0-RELEASE #0 releng/14.0-n265380-f9716eee8ab4: Fri Nov 10 05:57:23 UTC 2023    
 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
root@temp:/ #

Where is thunderbird, firefox, more...
Code:
root@temp:/ # pkg install thunderbird
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'thunderbird' have been found in the repositories
root@temp:/ # pkg install firefox
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'firefox' have been found in the repositories
root@temp:/ #
lsof here is..
Code:
root@temp:/ # pkg install lsof
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        lsof: 4.99.3_2,8

Number of packages to be installed: 1

117 KiB to be downloaded.

Proceed with this action? [y/N]: y
[1/1] Fetching lsof-4.99.3_2,8.pkg: 100%  117 KiB 119.7kB/s    00:01    
Checking integrity... done (0 conflicting)
[1/1] Installing lsof-4.99.3_2,8...
[1/1] Extracting lsof-4.99.3_2,8: 100%
=====
Message from lsof-4.99.3_2,8:

--
NOTE: Due to the way the FreeBSD build clusters make packages,
you may see a warning similar to the following:

lsof: WARNING: compiled for FreeBSD release 11.1-RELEASE-p6; this is 11.1-RELEASE-p4.

This is because the poudriere jails that build the packages don't have the  
corresponding kernel installed, so they don't know that the kernel version is different.

This warning can be ignored if you are using a system that is updated via freebsd-update
and are using pre-built packages.
root@temp:/ #
 
Can't we just have a sticky post about the fact that if there is any build issue for a port or its dependency, it will disappear until the build issue is fixed.
There are at least a dozens of post about missing packages that are the duplicate of the same issue: dependency build issue.
Like right here, there was a post with less than 2 hours about the same exact topics.
 
Which reminds me of another IMPORTANT point--yeah, I shouted. When you upgrade all available packages, there is a section where it says the following packages will be removed. (Removed might be all caps). Pay attention, it might take out a package that you need or at least really like. Sadly, I learned this the hard way, especially if you blindly clear cache after package upgrades and the old package is gone for good, and it's the week you you were too lazy to set up backups.
 
Just an idea, which makes pkg repo management a bit complicated.

When rebuild (including updates of itself and updates of which it depends on) happens, the pkgs seems to be deleted immediately now.

Dividing this behavior into 3 would help a fair amount of cases.

  1. In cases any of updates (itself and its dependencies) includes CVE info in its commit message, do just as done now for security.
  2. In cases shared library versions are bumped, do just as done now to avoid runtime breakages.
  3. In other cases (feature updates), remove old pkg only when updated ones are sanely built.

Not sure how hard implementing above is.

Maybe the 2nd one forces pkg-plist to be mandated to allow checks before official pkg build starts. Would need good tool for maintainers.
Include all possible files (if any of the options or flavors causes generating specific files, all of them should be appear) in pkg-plist file and make unneeded items deleted from temporary plist on build.

For example, x11/nvidia-driver/Makefile drops items from temporary plist file with conditionals (very complicated to maintain, thogh). Search keyword ${TMPPLIST} to find examples.
Maybe tool to generate these conditional removal codes to stub (currently used generally) Makefile (call Makefile.stub for example) to generate actual ports Makefile would be strongly wanted.

I hope there are much simple and better ideas and someone can actually implement (it clearly beyonds me).
 
When you upgrade all available packages, there is a section where it says the following packages will be removed. (Removed might be all caps). Pay attention, it might take out a package that you need or at least really like.
I know. But a backup solution for critical packages would not be absurd.
If someone wants to rather roll back to the last working/buildable version of a port, possibly also rolling back dependencies, just clone the ports tree, revert the commit(s) and build the port(s) and dependencies (or e.g. set up poudriere to build all your packages).
For ZFS on root users additionally: Create a Boot Environment (BE) before the upgrade.

Any mishap as a result of running a package upgrade can easily be reverted. Perhaps make a note or log of problematic packages (and verify) that (it) is stored outside the BE to investigate the existance of such packages at a later time. In cases where CVEs are involved you may still want to investigate immmediately.
 



The latter is pinned.
 
… Create a Boot Environment (BE) before the upgrade.

Always.

I install to the new environment, then make it temporarily active.

If boot of the new environment succeeds, then I make it active (no longer temporary).

… Perhaps make a note or log of problematic packages …

1723881938405.pngI have a routine that:
  • reduces noise, at the command line, to a reasonable minimum
  • copies essential information from /var/log/messages
  • copies /root/.history to the new environment, and so on.
Before closing the (Konsole) window and restarting the OS, I save the session as a text file.

Something extraordinary was recorded on 7th August (I encountered the symptom once, maybe twice in the past but didn't have a record). It might become an issue in GitHub.
 
Back
Top