After pkg upgrade firefox disappeared

K

koodikone

I ran "pkg upgrade" today and pkg decided to uninstall firefox. I tried to reinstall it but firefox package doesn't exist anymore (only firefox-esr-78). I am using the "latest" pkg repo and FreeBSD 12.2.

What is going on?
Code: 
# pkg upgrade
Updating FreeBSD repository catalogue...
[web] Fetching meta.txz: 100%    916 B   0.9kB/s    00:01    
[web] Fetching packagesite.txz: 100%    6 MiB   1.4MB/s    00:05
Processing entries: 100%
FreeBSD repository update completed. 32859 packages processed.
All repositories are up to date.
Checking for upgrades (8 candidates): 100%
Processing candidates (8 candidates): 100%
The following 9 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
        firefox: 83.0_2,2

Installed packages to be UPGRADED:
        aom: 2.0.0_1 -> 2.0.1
        dav1d: 0.7.1 -> 0.8.0
        ffmpeg: 4.3.1_6,1 -> 4.3.1_7,1
        glib: 2.66.2,1 -> 2.66.3,1
        liblz4: 1.9.2_1,1 -> 1.9.3,1
        librsvg2-rust: 2.50.0_1 -> 2.50.0_2
        mesa-libs: 20.2.0_1 -> 20.2.0_2
        spidermonkey78: 78.4.0 -> 78.4.0_1

Number of packages to be removed: 1
Number of packages to be upgraded: 8

The operation will free 227 MiB.
32 MiB to be downloaded.

Proceed with this action? [y/N]: y
[web] [1/8] Fetching spidermonkey78-78.4.0_1.txz: 100%    7 MiB 
[web] [2/8] Fetching mesa-libs-20.2.0_2.txz: 100%  410 KiB 420.2
[web] [3/8] Fetching librsvg2-rust-2.50.0_2.txz: 100%    2 MiB  
[web] [4/8] Fetching liblz4-1.9.3,1.txz: 100%  137 KiB 140.2kB/s
[web] [5/8] Fetching glib-2.66.3,1.txz:  92%    3 MiB   1.3MB/s [web] [5/8] Fetching glib-2.66.3,1.txz: 100%    3 MiB   1.1MB/s    00:03    
[web] [6/8] Fetching ffmpeg-4.3.1_7,1.txz:   6%    1 MiB   1.0[web] [6/8] Fetching ffmpeg-4.3.1_7,1.txz: 100%   15 MiB   1.2MB/s    00:13    
[web] [7/8] Fetching dav1d-0.8.0.txz: 100%  381 KiB 389.7kB/s    00:01    
[web] [8/8] Fetching aom-2.0.1.txz: 100%    3 MiB   1.6MB/s    00:02    
Checking integrity... done (0 conflicting)
[web] [1/9] Deinstalling firefox-83.0_2,2...
[web] [1/9] Deleting files for firefox-83.0_2,2: 100%
[web] [2/9] Upgrading liblz4 from 1.9.2_1,1 to 1.9.3,1...
[web] [2/9] Extracting liblz4-1.9.3,1: 100%
[web] [3/9] Upgrading mesa-libs from 20.2.0_1 to 20.2.0_2...
[web] [3/9] Extracting mesa-libs-20.2.0_2: 100%
[web] [4/9] Upgrading glib from 2.66.2,1 to 2.66.3,1...
[web] [4/9] Extracting glib-2.66.3,1: 100%
[web] [5/9] Upgrading dav1d from 0.7.1 to 0.8.0...
[web] [5/9] Extracting dav1d-0.8.0: 100%
[web] [6/9] Upgrading aom from 2.0.0_1 to 2.0.1...
[web] [6/9] Extracting aom-2.0.1: 100%
[web] [7/9] Upgrading spidermonkey78 from 78.4.0 to 78.4.0_1...
[web] [7/9] Extracting spidermonkey78-78.4.0_1: 100%
[web] [8/9] Upgrading librsvg2-rust from 2.50.0_1 to 2.50.0_2...
[web] [8/9] Extracting librsvg2-rust-2.50.0_2: 100%
[web] [9/9] Upgrading ffmpeg from 4.3.1_6,1 to 4.3.1_7,1...
[web] [9/9] Extracting ffmpeg-4.3.1_7,1: 100%
[code]

[code]
# pkg search firefox
firefox-esr-78.5.0_4,1         Web browser based on the browser portion of Mozilla
[/code][/code]
 
Build problems don't remove packages. If a package disappears from the repository they'll just show up as "orphaned". There are other reasons why a package would get removed, changes in the dependency chain is usually the reason.
 
All right, so I will just wait then until somebody fixes these dependency / build issues.

Have to read also more carefully in future what pkg is planning to remove -- this just happened on a jail specifically built to be a firefox instance...
 
koodikone said:
Have to read also more carefully in future what pkg is planning to remove
Click to expand...
That's why the default is 'N' (No), always carefully review what it wants to do before blindly hitting 'Y'. Post-pone the updates when you find out it wants to remove something it shouldn't. Figure out why and do the update when you understand the reason or know what to do to prevent it.
 
SirDice said:
Build problems don't remove packages. If a package disappears from the repository they'll just show up as "orphaned". There are other reasons why a package would get removed, changes in the dependency chain is usually the reason.
Click to expand...
I've had this happen when I changed the options of a package that Firefox depends on. You do have to build a full set of dependencies if you wanna mess with creating your own packages using Poudriere.
 
Dear koodikone,
it can be that your latest package is in /var/cache/pkg. Then it *might* work to re-install it by pkg add. I would not recommend that if you are happy with the ESR version for the meantime. There is a reason why it does not build anymore. Then some dependencies might have been replaced by new versions which do not match the old browser version.
 
I had the same problem and temporarily solved it by reinstalling older versions of dav1d and firefox from cache:
Bash: 
pkg delete dav1d
pkg add /var/cache/pkg/dav1d-0.7.1.txz
pkg add /var/cache/pkg/firefox-83.0_2,2.txz
It was necessary to reinstall dav1d because older firefox version required libdav1d.so.4 instead of libdav1d.so.5 that is installed by current dav1d version.
 
T-Daemon said:
To avoid www/firefox been removed upgrading the other packages you could lock it temporarily until the build problem has been solved (pkg-lock(8), pkg help lock).
Click to expand...
If I pkg-lock firefox, how will firefox be listed in the next pkg upgrade approval listings? Does it still show as to be removed, or is there some note that shows that firefox is locked, or ... ?

Where I'm going with this is I'm afraid I'll lock firefox and then forget to unlock it because pkg upgrade didn't tell me anything changed on the repo side of things.
 
jdrch said:
If I pkg-lock firefox, how will firefox be listed in the next pkg upgrade approval listings? Does it still show as to be removed,
Click to expand...
It won't be listed in any upgrade list.
jdrch said:
or is there some note that shows that firefox is locked, or ... ?
Click to expand...
There is no note. You can list the locked packages: pkg lock -l.

In retrospect, recommending to lock the program was a bad advice to give, it would have lead to a situation of library incompatibility, see post #9, dependency multimedia/dav1d.

Don't lock packages destined for removal!

In the past I've locked www/firefox once, I can't remember the circumstances, but I remember I had to sysmlink a few libraries of devel/icu to an older version firefox had complained about when starting. It's not advised to do so. Inadequate dependency versions of a application may provoke data loss (files the application has write access to, databases, etc.). Also if those changes are forgotten to revert it may conflict with the functionality of other programs eventually, and it would be hard to track them down. In my case I keept track by logging the changes I made, reverting them afterwards.
 
I recently had a similar problem with being unable to run mail/thunderbird the mail client from the same Mozilla stable. It moaned about a missing a dependency, which was indeed the dav1d pkg ("dav" ONE 'd') - specifically it wanted libdav1d.so.4 but did not see libdav1d.so.5, libdav1s.so.5.0.0 or libdav1s.so . Manually creating a symbolic link from the former filename to the middle one of the latter (being the actual library file) was sufficient to get the application running again.

Given the way that libraries (in this case in /usr/local/lib) are version-linked like this it is quite reasonable, though a nuisance to have to do, to set up a link of one minor version number version of a library to a higher minor version number...
 
SlySven said:
Manually creating a symbolic link from the former filename to the middle one of the latter (being the actual library file) was sufficient to get the application running again.
Click to expand...
This is going to haunt you later on. Never solve dependency issues this way.
 
Hang on though, the concept of versioning libraries is about maintaining a public API isn't it. So a library is given some new features and for other libraries/applications to use those new features they have to specify a minimum version. However, older libraries/applications that have not, by definition, been built to use the new features, might expect to see an older version but can use a newer one provided it provides the older API as well. For a minor (the y in an x.y.z) version number - it is probably safe to temporarily use the newer version.

?OTOH one does need to keep an eye on it for problems so your warning is not totally out of order...

Okay, would you consider changing your "Never" to "Be careful if you"?
 
I'm moving on to ground that I am not certain of my traction on but can you explain:
SirDice said:
It's not about the API, it's about the ABI.
Click to expand...
in this sort of context? Is there any sort of FreeBSD specific guidance on how either of these might be related to library versioning? I am genuinely curious on trying to understand this better...
 
SirDice said:
This is going to haunt you later on. Never solve dependency issues this way.
Click to expand...
better to use /etc/libmap.conf:

Code:
Code: 
[/usr/local/lib/seamonkey]
libffi.so.6 /usr/local/lib/libffi.so.7.1.0
# for when seamonkey results in libffi... not found ...

It was many years til I learned a format,
[program or library ]
[missing library ] [ actual library present on system WITH PATH]
which works here, the path, if not needed, included for future
edits.
 
SlySven said:
Is there any sort of FreeBSD specific guidance on how either of these might be related to library versioning?
Click to expand...
API issues would get resolved when you compile both the library and the application that used the library. As long as the API stays the same it's not going to matter if the version of the library changes. Once the library has been compiled however the entry points of the various functions and modules are set in stone, addresses and indexes are calculated and compiled in at a low-level. This is the ABI. If your application uses a different index (because it assumes a different version of the library) to jump in the table you might jump in the middle of some other code. Which can lead to segfaults, other "unexplained" crashes or weird behavior. Those version numbers are exactly there to prevent this from happening. However if you start symlinking different versions together you're going to make a giant mess of the one thing that actually stops these problems from happening. It is bad, NEVER (yes, I used that word again) do this.
 
You must log in or register to reply here.
Back
Top