Solved can we push a new packages full all at same time ?

fff2024g

fff2024g

dear freebsd :
can we push a new packages full all at same time ? don't push a part of app to new , and push a part of app to disappear . that was very bad for my production system. when i pkg upgrade , the system stop work. and need to wait for long time for new apps.
can we study fedora dnf update ? that is good . new guys , maybe my idea was not good. but this pkg upgrade make a big trouble for all. thanks. i love freebsd.
 
I don't see any big problems yet. There is a rescue kit from OpenZFS (BE, snapshot), there are alternatives. I noticed that Wayland and window managers for Wayland were not affected. But traditional systems based on X failed. So think about it... maybe sway/hyprland switch?
 
The issues weren't caused by anything pushed to the ports tree. Think about it, 'latest' built fine just before the 14.1 EoL. That 'latest' branch became the new 2025Q2 quarterly branch. There haven't been any meaningful, large, or impactful, changes being pushed to the ports tree in the mean time. So there's zero reason why both 'latest' and the new 'quarterly' ports trees would fail in such a catastrophic way. Ports committers and ports management always take very good care of the ports tree.

Also, https://forums.freebsd.org/threads/...-me-whats-going-on-with-pkg.97532/post-697803
 
I'm really amazed how many people flat out IGNORE what pkg is clearly telling them it is going to do (pkg 2.x even moved the 'packages to be removed' section to the bottom - BIG THANKS to whoever made that change!!) and then blame the OS/pkg/port maintainers/... Has Windows and Linux trained everybody to just ignore whatever a program is trying to tell you?

It kind of fits though that those people also don't use (or also ignore?) the forum search or just look at the first page of the list of latest threads.
AND ignore the fact that they can simply rollback to a snapshot from before they hosed their packages...
 
And you need to wean yourself off from the notion that a new version of the OS also means a whole bunch of changes to third party software as would be the case with Fedora (or most of the Linux distributions in general). The ports tree is its own 'entity', whatever is in the ports tree has basically no relation to the version of the OS, all (supported) versions of FreeBSD use one and the same ports tree. The only exception are ports (the DRM modules for example) that require a certain kernel/OS feature that's only available from a specific OS version onward.
 
Now, at the risk of coming across as snarky (not my intention!) but I still got to wonder: why would you want to upgrade production systems ASAP? Especially when the update had nothing to do with security concerns but is rather a bit of a rebuild? Surely that can wait for a few days (or a week)? Especially when you're getting error messages during the first attempt(s).

Second... I know this isn't a feasible option for everyone, but I just can't help but mention anyway: using the ports collection itself comes with a ton of advantages, such as having full control over any kind of upgrade process, but also being able to customize your servers to your own standards and/or needs. For example: why hang onto potentially 'dangerous' routines if you don't really need them? (I always make sure that DAV isn't part of my Apache builds because I/we never had any use for it).

Sure, it'll take a bit more time to sort out your updates, but at the same time you're also not going to get "bit" by issues like these either. Because you'd be right on top of them in the first place.

And if you maintain multiple servers? Then setting up & maintaining your own package repository is honestly hardly as difficult as it may seem at first. Build your ports on a dev. server (which can also serve as quality control!) then provide the build packages in a repository which can be used by pkg on other servers (see /etc/pkg/FreeBSD.conf for a good starting example).
 
ShelLuser said:
Now, at the risk of coming across as snarky (not my intention!) but I still got to wonder: why would you want to upgrade production systems ASAP? Especially when the update had nothing to do with security concerns but is rather a bit of a rebuild? Surely that can wait for a few days (or a week)? Especially when you're getting error messages during the first attempt(s).

Second... I know this isn't a feasible option for everyone, but I just can't help but mention anyway: using the ports collection itself comes with a ton of advantages, such as having full control over any kind of upgrade process, but also being able to customize your servers to your own standards and/or needs. For example: why hang onto potentially 'dangerous' routines if you don't really need them? (I always make sure that DAV isn't part of my Apache builds because I/we never had any use for it).

Sure, it'll take a bit more time to sort out your updates, but at the same time you're also not going to get "bit" by issues like these either. Because you'd be right on top of them in the first place.

And if you maintain multiple servers? Then setting up & maintaining your own package repository is honestly hardly as difficult as it may seem at first. Build your ports on a dev. server (which can also serve as quality control!) then provide the build packages in a repository which can be used by pkg on other servers (see /etc/pkg/FreeBSD.conf for a good starting example).
Click to expand...
Given that most complaints about "pkg removed X" are concerning KDE or other DEs, all those server-specific points don't really apply. Other than that: full ACK. There's also pkg lock to just keep packages where the port build is currently broken - or just pkg upgrade <pkgname> what you really and urgently want/need to update.

I've been building packages for my servers and desktop for years now using poudriere, and TBH especially for my desktops/laptops I wouldn't want it any other way - there are a lot of ports that would drag in TONS of bloated dependencies in their default configuration. Everything related to KDE/qt6/kf6 comes to mind - additionally to the fact that qt6 still seems to be of beta-quality at best and has been causing problems for months now... but it seems that's what you get with linux-centric software nowadays - "it works on their PC", so it is forced upon everyone. I started to simply replace programs that have such bloated/unstable dependencies and avoid anything KDE-related, as it can't get any more linux/systemd-centric as KDE has become...
 
  • Like
Reactions: mer
I have always tried to keep updated with respect to base (freebsd-update) because those are almost defined to be security and critical bug related. Doing that has very little (no?) impact on installed applications (packages/ports).

Waiting for all over 32000 (I'm not sure of the exact number) to successfully build and get pushed to all the package repos before announcing "they're ready" would lead to more consistent repos BUT do you need all of those ports?
Do this on your machines:

pkg prime-list | wc -l

and see how many packages you actually have installed.
My machines, which are primarily desktop/daily use have 70-100 packages installed.
So me waiting for all the packages to be built and pushed is counter productive.
Getting that count also ties into what SirDice has said in other threads about setting up your own poudiere environment: you don't need to build everything, you only need to build what you actually use (and any build dependencies).

I've been using FreeBSD and packages for a long time, yes there are occasional problems, but honestly very few.

How to mitigate:
  • Set up your own Poudiere ports build environment and control everything
  • Use ZFS and Boot Environments. freebsd-update will create a new BE for you when updating base, but you can manually create a new one before doing quarterly package updates. You can leverage both to "freebsd-update across releases" like 13.x to 14.x so you only reboot once into a version consistent system. If it's broken, trivial reboot into the previous working BE and be back in business.
  • The "-n" option on pkg commands is your friend. It means "don't do anything just tell me what you would do". I always run the commands first with this option, usually redirect output to a file that I look at in an editor. Has saved me a few times over the years.
  • Be patient. I hate it when things are broken, but since most of the folk on the project are volunteers, life may get in the way.
  • Mailing lists keep you informed.
Sorry if this got long.
 
Dear all masters of freebsd :
thanks for your reply . i am new guy in freebsd, now studying status. so i ask the simple question . i will be careful to use pkg upgrade . thanks. :)
 
You must log in or register to reply here.
Back
Top