Where are we at with this week's pkg upgrade

byrnejb

byrnejb

I did a pkg upgrade this week and as a result atril was removed because webkit2-gtk3 was removed. I understand that there is a built problem somewhere that resulted in this but really, why was it thought to be a good idea to put out as a general release something that would remove the default pdf reader used by mate desktop users?

Would it not have been more prudent to delay the release until everything worked?
 
Here on forum there is thread, which explained "quarterly" just as snapshot of "latest" in the beginning. And this is not "stable".
Checking build status before publishing quarterly is good suggestion.

During previous Quarterly Quake people lost their browsers for a while...
 
So what repo should one configure so as to avoid this sort of thing? Or is there no such thing as a truly 'stable' stable release? (note: not STABLE)
 
New build was done on quarterly; Thu, 10 Apr 2025 01:01:15 GMT. It fixed a couple of things, unfortunately not on webkit2-gtk, that's still failing.
 
What's your definition of "stable"? Because it doesn't mean what you think it does.
 
CeXP1917 said:
Here on forum there is thread, which explained "quarterly" just as snapshot of "latest" in the beginning. And this is not "stable".
Click to expand...
"latest", yes. "quarterly", maybe, but why after a routine pkg upgrade did it break my 14.2-RELEASE-p1 FreeBSD 14.2-RELEASE-p1 GENERIC amd64 Xfce environment? :-/
 
I guess that would be nice having some policies that govern the package manager to avoid disruptions like this.

If you set your policies as "Desktop" perhaps an algorithms can retain to upgrade some packages till all the dependencies are fully satisfied instead of removing half desktop, and let the package manager to install only the security updates.

It looks a nice way to be polite with Desktop users... 🤔
 
freezr said:
I guess that would be nice having some policies that govern the package manager to avoid disruptions like this.

If you set your policies as "Desktop" perhaps an algorithms can retain to upgrade some packages till all the dependencies are fully satisfied instead of removing half desktop, and let the package manager to install only the security updates.

It looks a nice way to be polite with Desktop users... 🤔
Click to expand...
If you're using ZFS as your filesystem you can play with boot environments like explained in this tutorial :
https://klarasystems.com/articles/managing-boot-environments/
 
freezr said:
If you set your policies as "Desktop" perhaps an algorithms can retain to upgrade some packages till all the dependencies are fully satisfied instead of removing half desktop, and let the package manager to install only the security updates.
Click to expand...
A problem with this is you wind up with a potentially broken system, not just some missing packages.
 
With this latests upgrade I am now seeing this:
Code: 
[root@gway04 ~ (master)]# pkg check -s caja
Checking caja:   0%
caja-1.28.0_1: checksum mismatch for /usr/local/share/mime/XMLnamespaces
caja-1.28.0_1: checksum mismatch for /usr/local/share/mime/aliases
caja-1.28.0_1: checksum mismatch for /usr/local/share/mime/generic-icons
caja-1.28.0_1: checksum mismatch for /usr/local/share/mime/globs
caja-1.28.0_1: checksum mismatch for /usr/local/share/mime/globs2
caja-1.28.0_1: checksum mismatch for /usr/local/share/mime/magic
caja-1.28.0_1: checksum mismatch for /usr/local/share/mime/mime.cache
caja-1.28.0_1: checksum mismatch for /usr/local/share/mime/subclasses
caja-1.28.0_1: checksum mismatch for /usr/local/share/mime/treemagic
caja-1.28.0_1: checksum mismatch for /usr/local/share/mime/types
Checking caja: 100%
[root@gway04 ~ (master)]# pkg install -f caja
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be REINSTALLED:
    caja-1.28.0_1

Number of packages to be reinstalled: 1

Proceed with this action? [y/N]: y
[1/1] Reinstalling caja-1.28.0_1...
[1/1] Extracting caja-1.28.0_1: 100%
==> Running trigger: desktop-file-utils.ucl
Building cache database of MIME types
==> Running trigger: shared-mime-info.ucl
Building the Shared MIME-Info database cache
==> Running trigger: gtk-update-icon-cache.ucl
Generating GTK icon cache for /usr/local/share/icons/hicolor
==> Running trigger: glib-schemas.ucl
Compiling glib schemas
Warning: Schema “org.gnome.system.locale” has path “/system/locale/”.  Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated.
Warning: Schema “org.gnome.system.proxy” has path “/system/proxy/”.  Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated.
Warning: Schema “org.gnome.system.proxy.http” has path “/system/proxy/http/”.  Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated.
Warning: Schema “org.gnome.system.proxy.https” has path “/system/proxy/https/”.  Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated.
Warning: Schema “org.gnome.system.proxy.ftp” has path “/system/proxy/ftp/”.  Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated.
Warning: Schema “org.gnome.system.proxy.socks” has path “/system/proxy/socks/”.  Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated.
[root@gway04 ~ (master)]# pkg check -s caja
Checking caja:   0%
caja-1.28.0_1: checksum mismatch for /usr/local/share/mime/XMLnamespaces
caja-1.28.0_1: checksum mismatch for /usr/local/share/mime/aliases
caja-1.28.0_1: checksum mismatch for /usr/local/share/mime/generic-icons
caja-1.28.0_1: checksum mismatch for /usr/local/share/mime/globs
caja-1.28.0_1: checksum mismatch for /usr/local/share/mime/globs2
caja-1.28.0_1: checksum mismatch for /usr/local/share/mime/magic
caja-1.28.0_1: checksum mismatch for /usr/local/share/mime/mime.cache
caja-1.28.0_1: checksum mismatch for /usr/local/share/mime/subclasses
caja-1.28.0_1: checksum mismatch for /usr/local/share/mime/treemagic
caja-1.28.0_1: checksum mismatch for /usr/local/share/mime/types
Checking caja: 1

What is going on?

I am getting a similar report for:
Code: 
mate-control-center-1.28.1_2: checksum mismatch for /usr/local/share/applications/mimeinfo.cache
 
byrnejb said:
What is going on?
Click to expand...
SirDice

Post in thread 'pkg repo quoterly vs latest'

SirDice said:
but you're very likely to run into the exact same build issues.
Click to expand...
After reading some posts on freebsd-ports mailing list, I'm starting to believe the issues are caused by the package build hosts themselves (apparently they've been hit by a bug in -CURRENT), it's not the actual ports that are bad. I've started a new build on my own build server, added Gnome, Mate and XFCE, and I'll try and see how far my system can build them. Although I am also running -CURRENT on my build host, I may have a -CURRENT from before the bug.
  • Thanks
  • Like
 
mer said:
A problem with this is you wind up with a potentially broken system, not just some missing packages.
Click to expand...

It was just a recommendation, there should be a way to hold packages until all the dependencies are cleared and ready to go without breaking nothing... 🤔
 
freezr said:
It was just a recommendation, there should be a way to hold packages until all the dependencies are cleared and ready to go without breaking nothing... 🤔
Click to expand...
I understand Just a recommendation and it's not a bad one. I think there may be a few too many threads sometimes between packages.

But that is also why I use ZFS everywhere: I have a working 14.1-RELEASE BE and a "mostly working" 14.2-RELEASE BE where I know I have broken stuff (for me right now it's gnucash which depends on webkit2).
 
SirDice said:
What's your definition of "stable"? Because it doesn't mean what you think it does.
Click to expand...
My working definition would be - all of the released software works as expected and nothing is removed from the previous release that does not have a working replacement in the current release. I really do not see any of that as being a revolutionary requirement.
 
mer said:
I understand Just a recommendation and it's not a bad one. I think there may be a few too many threads sometimes between packages.

But that is also why I use ZFS everywhere: I have a working 14.1-RELEASE BE and a "mostly working" 14.2-RELEASE BE where I know I have broken stuff (for me right now it's gnucash which depends on webkit2).
Click to expand...

Or eventually it might be advertising better when a critical library is taking down half third party so anyone can decide to upgrade or to not upgrade, or another solution might be to upgrade only packages flagged with security updates and see if the resolver doesn't remove anything...

From my perspectives these are the little things that make FreeBSD more desktop friendly... ☺️
 
  • Like
Reactions: mer
fmc000 said:
That's basically what happens if you answer "N" to the pkg removal request. Your system will continue working as before.
Click to expand...

That is why it would be good to separate regular updates from security updates, so you can trigger the latter when something went wrong with regular updates... 🤔
 
fmc000 said:
That's basically what happens if you answer "N" to the pkg removal request. Your system will continue working as before.
Click to expand...
System will continue working if there is system with software. What about people, who dont have local repo/poudriere/etc? What, for example, will see newcomer from Linux world, who want to look at FreeBSD and maybe switch? "OK, I installed system, but there is no %I_need_this_pkg% and port is broken. @%$#@!"

About people, who saw list pkg for deleting, but pressed Y: maybe -/psychological aspect based on experience from other systems/- they though something like "thats ok, packages just was renamed".
 
CeXP1917 said:
What about people, who dont have local repo/poudriere/etc? What, for example, will see newcomer from Linux world, who want to look at FreeBSD and maybe switch? "OK, I installed system, but there is no %I_need_this_pkg% and port is broken. @%$#@!"
Click to expand...
There shouldn't be much of a problem if they make sure to understand what they're doing. I mean, you don't have to start with make deinstall reinstall clean if you're unsure. A simple make build is a good way to start and check if a port actually builds before messing with your actual installation.

And well, there's always ports-mgmt/portmaster which is a very lightweight way to build items in the ports collection. Of course it needs configuring, but one solid feature is the ability to make a backup of the currently installed port before installing the new one; thus making sure you can always easily revert any changes.
 
ShelLuser said:
I mean, you don't have to start with make deinstall reinstall clean if you're unsure.
Click to expand...
Yep, but problem is "make install/pkg install" on fresh systems, when there is no pkg and port in quarterly and latest, especially pairs compiler+application (Caddy and Go, as somebody asked). For new people it may be not so easy solve this.
 
You must log in or register to reply here.
Back
Top