FreeBSD Foundation Flounders on 15 with Rust, pkgbase, and KDE

kpedersen said:
And so making this worse helps this?
Click to expand...
It doesn't live up to that idea, it never lived up to that idea, maybe that idea is yours, not the developers?

The fact that you consider stripping down the OS for purpose built installs (that may or may not be compliant to some standard the purpose does not require) "ricing" really just says to me you don't consider VM computing as important, despite it being most of what's happening on the internet. They can use your "rm" technique when they try and remove something important (maybe awk!) and get a bunch of dependency removal notices for things they want installed.... That's the whole point.

If you think the issue is "support" in these forums 🤣 Most people with nonstandard installs will be using prebuilt containers that's going to fall under the same category of "unsupported versions." More people using FreeBSD is naturally going to generate more "support" issues. This one is real simple: go ask whoever made the thing.
 
ralphbsz said:
I consider this to be a bad thing, not a good thing. When I'm on a major version (like 13), then all programs installed as part of base will not have major version changes, until I upgrade to the next major version (like 14). This greatly reduces the amount of breakage that minor or patch upgrades will cause.
Click to expand...
I agree with this. I think the pkgbase "release cycle" should follow what we've come to expect from the standard cycle. So start with 14.0-RELEASE-p0 (first release on 14.x branch). At that point pkgbase should be coherent. As time goes on, we wind up with CVE's against 14.0-RELEASE-p0, at some point enough accumulates to create 14.0.-RELEASE-p1 (according to freebsd-update). If pkgbase waits for 14.0-RELEASE-p1 then I think we maintain coherency and freebsd-update behavior. Again, I think "process" to hold off updating pkgbase until/as part of releasing the -p1 maintains the current behavior.
But I acknowledge it may be easy to break this.
 
I appreciate bringing this up.

I can see how streamlining the OS to use pkg for everything makes some sense, as long as we still maintain a separate / for base and /usr/local for third party. I need to watch how this develops.

If KDE is an option, I don't think that's a negative. Just define some predefined packages to install after the base OS has been setup.
 
JohnK said:
so, what's the problem if your system gets borked by freebsd-update or pkg? same difference; BE to the rescue! "Look ma, no hands!"

EDIT:
I'm making the assumption that if either (freebsd-update or pkg) works, then there is no issue as to which tool is used.
Click to expand...
From what I've seen pkgbase doesn't automatically create a new boot environment like freebsd-update does. So another manual step that will likely bite more people leading to more problem reports etc.

I think part of the problem here is that things are set up so you just have a new repository and all repositories are updated by default when your run "pkg upgrade". You can specify a repository to operate on but by default all of them are operated on. It should have been the other way around I think or made as a configurable (maybe it is and I've missed it). At that point new verbs could have been added like "pkg upgradebase" which could have automatically created a boot environment.
 
Yeah.. the degradation of these forums isn't getting better. The line between here and reddit is thinning by the day. Too many misinformed trolls here.
 
dkh said:
From what I've seen pkgbase doesn't automatically create a new boot environment like freebsd-update does. So another manual step that will likely bite more people leading to more problem reports etc.
Click to expand...
This is a true statement, one I've fought with for a bit.
I understand that freebsd-update creates a new BE representing the system BEFORE any updates are applied, and one has to remember this happens so you periodically prune using bectl destroy -o old ones.
But I've been following a process to manually create a new BE, named to reflect the NEW version, then do freebsd-update and pkg-static commands that chroot into that new BE. That means my current BE is the system right now, the new BE is "the new system", the new BE should be coherent with base version and packages, a single reboot into the new BE instead of potential multiple reboots.
The new BE and chroot is especially useful when going across releases like 14.x to 15.x. Very easy rollback to working system.

So to me, pkgbase should not change my process assuming all the chroot stuff still works (I imagine it will).
 
cy@ said:
Agreed. And the Foundation isn't pushing anything WRT Rust.

Again, where do people get these conspiracies from?
Click to expand...
I guessing "someone said something at a developer summit about should we look at this" and it became gospel instead of something to be discussed.
 
I know that in this forum there is a bias against the desktop users, however I was looking at the wiki page and it looks like rather than streaming line the operations, now those are even more convoluted and require the implicit use of ZFS, for instance:

Major version upgrades​


For 14 (versions of which include RELEASE) to 15 (not yet RELEASE), the url line of FreeBSD-base.conf must include one of the following:

An ABI environment variable is required.

Example commands, for AMD64:

  • # env ABI=FreeBSD:15:amd64 pkg-static upgrade
    # env ABI=FreeBSD:15:amd64 pkg-static install -nU -r FreeBSD-base -g 'FreeBSD-*'
When prompted to run pkg bootstrap -f: do not.

The upgrade will be broad – not limited to base. Either:

  • avoid using non-base software, such as a desktop environment, during the upgrade period; or
  • create and mount a new ZFS boot environment, then use the --rootdir option of pkg-static(8) to target the mount point of the environment
The dry run installation, after the upgrade, lists non-installed base packages. Packages that exist for 15 but not 14 include FreeBSD-ntp.

After the upgrade and any other required installation:

  1. if you upgraded a new boot environment, make it active or temporarily active
  2. restart the OS.
Click to expand...

🤯😵‍💫😭
 
Came to this thread late, so thought I'd run pkgbasify.lua on an instance I have to see what the real-world deal actually is. So basically someone's just injected pkg with steroids to look after base too, not the big deal I thought it was.

Code: 
cat  FreeBSD-base.conf
FreeBSD-base: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/base_release_3",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
root@BuildBSD:/usr/local/etc/pkg/repos# bectl list
BE                              Active Mountpoint Space Created
14.3-RELEASE_2025-07-02_203548  -      -          3.69G 2025-07-02 20:35
default                         NR     /          43.0G 2025-01-10 07:38
pre-pkgbasify_2025-07-29_171813 -      -          21.1M 2025-07-29 17:18
root@BuildBSD:/usr/local/etc/pkg/repos# freebsd-version -ukr
14.3-RELEASE-p1
14.3-RELEASE-p1
14.3-RELEASE-p1
root@BuildBSD:/usr/local/etc/pkg/repos# freebsd-update fetch install
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 14.3-RELEASE from update2.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.
Fetching 4 files... .. done.
The following files will be updated as part of updating to
14.3-RELEASE-p1:
/boot/kernel/zfs.ko
/lib/libzpool.so.2
/rescue/[
/rescue/bectl
/rescue/bsdlabel
/rescue/bunzip2
/rescue/bzcat
/rescue/bzip2
/rescue/camcontrol
/rescue/cat
/rescue/ccdconfig
/rescue/chflags
/rescue/chgrp
/rescue/chio
/rescue/chmod
/rescue/chown
/rescue/chroot
/rescue/clri
/rescue/cp
/rescue/csh
/rescue/date
/rescue/dd
/rescue/devfs
/rescue/df
/rescue/dhclient
/rescue/disklabel
/rescue/dmesg
/rescue/dump
/rescue/dumpfs
/rescue/dumpon
/rescue/echo
/rescue/ed
/rescue/ex
/rescue/expr
/rescue/fastboot
/rescue/fasthalt
/rescue/fdisk
/rescue/fetch
/rescue/fsck
/rescue/fsck_4.2bsd
/rescue/fsck_ffs
/rescue/fsck_msdosfs
/rescue/fsck_ufs
/rescue/fsdb
/rescue/fsirand
/rescue/gbde
/rescue/geom
/rescue/getfacl
/rescue/glabel
/rescue/gpart
/rescue/groups
/rescue/gunzip
/rescue/gzcat
/rescue/gzip
/rescue/halt
/rescue/head
/rescue/hostname
/rescue/id
/rescue/ifconfig
/rescue/init
/rescue/ipf
/rescue/iscsictl
/rescue/iscsid
/rescue/kenv
/rescue/kill
/rescue/kldconfig
/rescue/kldload
/rescue/kldstat
/rescue/kldunload
/rescue/ldconfig
/rescue/less
/rescue/link
/rescue/ln
/rescue/ls
/rescue/lzcat
/rescue/lzma
/rescue/md5
/rescue/mdconfig
/rescue/mdmfs
/rescue/mkdir
/rescue/mknod
/rescue/more
/rescue/mount
/rescue/mount_cd9660
/rescue/mount_msdosfs
/rescue/mount_nfs
/rescue/mount_nullfs
/rescue/mount_udf
/rescue/mount_unionfs
/rescue/mt
/rescue/mv
/rescue/nc
/rescue/newfs
/rescue/newfs_msdos
/rescue/nos-tun
/rescue/pgrep
/rescue/ping
/rescue/ping6
/rescue/pkill
/rescue/poweroff
/rescue/ps
/rescue/pwd
/rescue/rcorder
/rescue/rdump
/rescue/realpath
/rescue/reboot
/rescue/red
/rescue/rescue
/rescue/restore
/rescue/rm
/rescue/rmdir
/rescue/route
/rescue/routed
/rescue/rrestore
/rescue/rtquery
/rescue/rtsol
/rescue/savecore
/rescue/sed
/rescue/setfacl
/rescue/sh
/rescue/shutdown
/rescue/sleep
/rescue/stty
/rescue/swapon
/rescue/sync
/rescue/sysctl
/rescue/tail
/rescue/tar
/rescue/tcsh
/rescue/tee
/rescue/test
/rescue/tunefs
/rescue/umount
/rescue/unlink
/rescue/unlzma
/rescue/unxz
/rescue/unzstd
/rescue/vi
/rescue/whoami
/rescue/xz
/rescue/xzcat
/rescue/zcat
/rescue/zdb
/rescue/zfs
/rescue/zpool
/rescue/zstd
/rescue/zstdcat
/rescue/zstdmt
/usr/lib/libzpool.a
Creating snapshot of existing boot environment... done.
Installing updates...
Restarting sshd after upgrade
Performing sanity check on sshd configuration.
Stopping sshd.
Waiting for PIDS: 74689.
Performing sanity check on sshd configuration.
Starting sshd.
 done.
root@BuildBSD:/usr/local/etc/pkg/repos# freebsd-version -ukr
14.3-RELEASE-p1
14.3-RELEASE-p1
14.3-RELEASE-p1
root@BuildBSD:/usr/local/etc/pkg/repos# pkg update
Updating FreeBSD-kmods repository catalogue...
FreeBSD-kmods repository is up to date.
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
Updating poudriere repository catalogue...
poudriere repository is up to date.
All repositories are up to date.
root@BuildBSD:/usr/local/etc/pkg/repos# pkg upgrade
Updating FreeBSD-kmods repository catalogue...
FreeBSD-kmods repository is up to date.
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
Updating poudriere repository catalogue...
poudriere repository is up to date.
All repositories are up to date.
Checking for upgrades (0 candidates): 100%
Processing candidates (0 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.

So, I've seen it, no big deal, wound back my instance and carried on with my day.

Curious why all the /rescue/* stuff got patched invoking a "freebsd fetch install" though.
 
freezr said:
I know that in this forum there is a bias against the desktop users, however I was looking at the wiki page and it looks like rather than streaming line the operations, now those are even more convoluted and require the implicit use of ZFS, for instance:



🤯😵‍💫😭
Click to expand...
Perhaps convoluted, but currently ZFS is the only filesystem that can support "doing operations that are effectively chroot".
UFS: if you want to emulate the A/B root behavior of typical embedded systems, you can but you need to start out that way, you need to gpart create parallel partitions/filesystems (vermaden has at least one article about this I think) so I think in theory you could do this with UFS.
ZFS and BEs just make it easier.

I'm not sure the forums have a bias against desktop users, simply ask "how many people posting here are using a browser on a system running FreeBSD". By definition, that is a desktop user. I think the bias is against expecting a desktop and expecting everything to work like MacOS/Windows by default.

Just my opinions as a "FreeBSD desktop user since around the 3.x days".
 
JohnK said:
*sigh* you obviously haven't learned anything from this thread. Pay attention! ...Any option to "click yes" or one which requires "accommodation" shall not be tolerated and should be ripped out from the root!
Click to expand...
Oh so the forum should have some kind of Vulcan mind meld to "know" who I should ignore. :)
 
JohnK said:
yes, but not me because I only say important things.
Click to expand...
Perspective. "important" often depends on where one stands. "Buy One Get One Free" when standing outside a donut shop, yeah that's important. Standing outside a Dr office for colonoscopy? Yeah, not so much.
 
RetroComputingCollector said:
I sadly have the feeling the foundation will stay on the Rust, KDE, and pkgbase train to "catch up" with Linux, when what they really should have done is be glad that Linux hasn't caught up with FreeBSD. Also, the Laptop and Desktop Working Group seems to care more about getting Linux converts instead of staying mainly loyal to FreeBSD's main targets: Servers and Technical Workstations.
Click to expand...
The way I see it, the Linux camp does have some good ideas, but it's FreeBSD that keeps getting them right. PkgBase is one such example, ZFS is another. FreeBSD, IMHO, does have the components to get a LOT of things right, just by building on what they already have.

I don't care about Rust any more, but KDE is important to me. And, the Foundation had a dedicated team to work on integrating KDE into FreeBSD for a pretty long time - since FreeBSD 4.x days:
SirDice said:
Oh look, the 4.11 install disks came in two different 'flavors', one with KDE and one with Gnome.

Click to expand...

I'd think that says something about how important KDE is to FreeBSD. KDE can be as convenient as you can make it, and Konsole exposes ALL of the command-line goodies of FreeBSD until you can't take it any more! 😏😈
 
You must log in or register to reply here.
Back
Top