drm-fbsd13-kmod is gone (in favor of drm-510-kmod)

astyle, you're confusing major and minor. 13.x (from the stable/13 branch) is supported for 5 years (and indeed, this will end in 2026). As I said, you are obliged to follow the minor releases during that time. And the transition phases for these are 3 months.

A minor release doesn't change ABI (so it won't break any existing software, there's no need to reinstall packages, etc), therefore all you need is a small maintenance window, very similar to a simple patch release.
 
zirias@ said:
astyle, you're confusing major and minor. 13.x (from the stable/13 branch) is supported for 5 years (and indeed, this will end in 2026). As I said, you are obliged to follow the minor releases during that time. And the transition phases for these are 3 months.

A minor release doesn't change ABI (so it won't break any existing software, there's no need to reinstall packages, etc), therefore all you need is a small maintenance window, very similar to a simple patch release.
Click to expand...
Ah, stable is for major, but -RELEASE is for minor??? yeah, then patchlevels -pN wouldn't be of any help...
 
astyle said:
Ah, stable is for major, but -RELEASE is for minor??? yeah, then patchlevels -pN wouldn't be of any help...
Click to expand...
Not exactly, "major" is just the first number in the version... So there are many minor releases in one major (and there's not "the" one major relase, but at any time, there's a current minor release of each supported major...). Technically, more or less yes, as all releases for the same major are from the same stable branch, so support time for that branch equals support time for a major release, and that's IIRC 5 years.
 
zirias@ said:
Not exactly, "major" is just the first number in the version... So there are many minor releases in one major (and there's not "the" one major relase, but at any time, theres a current minor release of a major...). Technically, more or less yes, as all releases for the same major are from the same stable branch, so support time for that branch equals support time for a major release, and that's IIRC 5 years.
Click to expand...
So, would 13.0 be a major or minor release??? I'd think that .0-RELEASE would be a major release, but it seems like it's getting treated as a minor release here...
 
Does this self-quote answer this question? :-/
zirias@ said:
there's not "the" one major relase, but at any time, there's a current minor release of each supported major
Click to expand...

IOW, every release is a "minor release", and part of a "major release". Maybe using a wording with "version" instead of "release" would be better. (strike that, then you could ask "is 13.0 a major version", leading to the same confusion... hehe)
 
www.freebsd.org

Release Information

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.
www.freebsd.org www.freebsd.org

says exactly what "production" releases are currently supported, what is EOL.
The overlap of 13.0 and 13.1 until 13.0 went EOL meant that all packages were built against Lowest Common Denominator, or 13.0. That meant any changes to any packages were based on 13.0. Things like drm-kmod were bound to whatever was in the kernel for 13.0. Honestly, to the best of my recollection, this has been the "truth" for as long as I can remember (which is probably only 11.x for me using binary updates, before that I always built from source, base and ports).

The original post in this thread merely pointed out "13.0 is EOL so now drm-kmod is based on whatever support is in the 13.1 kernel". The implication of that is "a drm-kmod built against 13.1 could break if installed on a 13.0 system"
My assumption here is trying to build drm-510-kmod on a 13.0 system would fail. zirias@ is that a valid assumption?

Perhaps the pkg command should hard fail if the versions are "greater than or equal to":
Pkg repo built against 13.1, pkg command is being run on a 13.0 system, pkg command should hard fail everything and say "build from ports". It would be a pain for a lot of applications that really don't depend on kernel ABI, but I think having all of them fail with an explicit message "Your version is EOL, if you want to use current packages you need to update" would be better.

Didn't we have a thread recently similar to this? Someone complained that there were no official package repos for an EOL 12.x or 11.x system?
 
  • Like
Reactions: mer
zirias@ said:
This wouldn't help either, as soon as 13.0 was EoL, support for it was removed from the ports tree.
Click to expand...
I was thinking more generically:
if the pkg command reported it's version ("Hey repo, I'm being run on a 13.0 system") the repo could respond with a hard fail of "So sorry, you must be at least 13.1 to use this repo"
That logic would work during the overlap (repo built against 13.0, 13.0 and 13.1 are valid)
Yes it means that some packages that would normally be fine won't be upgraded, but it would tend to force users to:

upgrade base so they can use prebuilt packages
start building ports against their current/static base
stay static and never upgrade base or packages

My personal opinion is everyone should upgrade sooner rather than later, but they need to feel comfortable. I tend to run pkg upgrade every couple weeks so I pick up firefox/etc upgrades quicker, but running freebsd-update I wait a week or two letting problems shake out. I just don't think the project should maintain official repos for EOL releases.
 
mer said:
My personal opinion is everyone should upgrade sooner rather than later, but they need to feel comfortable. I
Click to expand...
Or at least have pkg give a message on each run that it can break their system.

In the end it's a learning experience for me. The FreeBSD package tool can sometimes install kernel modules that are incompatible with the running kernel, and remove drivers that were working, and the developers consider that a problem for the end user to solve because hey, EOL. Not our problem buddy. if you didn't want us to break your server you should have upgraded.

I've certainly learned something about FreeBSD.
 
Harry Stone said:
I've certainly learned something about FreeBSD.
Click to expand...
True, but how many times will a Windows/iOs/Android update break something and you don't get any answers? Here, you got answers. You man not like the anwers, but you got them.
Keeping up to date is always an interesting/fragile thing. You want to update to get latest security patches but "if it ain't broke don't fix it"

My opinions follow. Agree, disagree, tell me I'm an a***hole, all fine with me.

For the record, I've been where you are in the past. But I looked at it from the other side: "Homer Simpson doh I was stupid" and should have upgraded. A flip side would have been doing "pkg upgrade -n" and seeing something odd around drm-kmod stuff and making a choice "should I stay or should I go". To me, no blame here on anyone, just a misunderstanding about "things".
 
It seems to me like having 'pkg upgrade' do nothing at all on an EOL system would solve this problem, and also there would be no need to try to justify it making changes to a system that is supposed to be at end of life anyway.
 
Harry Stone said:
It seems to me like having 'pkg upgrade' do nothing at all on an EOL system would solve this problem, and also there would be no need to try to justify it making changes to a system that is supposed to be at end of life anyway.
Click to expand...
I'm not going to argue against that, but it may break POLA.
 
mer said:
I'm not going to argue against that, but it may break POLA.
Click to expand...
I see your point. If there's a long standing practice of EOL systems getting updates it might not be obvious to users that they've stopped without at the very least a message telling them so.

On the other hand, why do EOL systems get updates anyway? Maybe zirias should have never been put in this position in the first place.
 
Oh, I'm pretty sure this warning works (at least IIRC, it's "just" a warning as long as the ABI still matches, and this would make sense because without ABI changes, >99% of all packages are expected to still work). If you didn't read all the output carefully, you probably just didn't see it.

FreeBSD doesn't prevent "foot shooting" (you could even override a "fatal" problem like wrong ABI if you want). You can always do unsupported things, then the system assumes you know what you're doing...

You could argue pkg should outright prevent to install anything on an EoL version. Then we'd see even more threads from people complaining they can't install anything on their EoL system ? (and they might rightfully ask, if 99% of packages would still work, why am I forced not to use them?)

In the end, it's simple. To avoid trouble, stick with what's supported. And IMHO, a transition phase of 3 months should be long enough for everyone, after all, a minor upgrade is quick and non-breaking. Otherwise, you could even blame it on the system when your server is cracked after you didn't install a security update....

BTW, "break your system" is strong wording for what happened here. A driver doesn't work any more. And all you have to do to make it work again is upgrade your system to 13.1. Nothing needs to be reinstalled or "fixed" otherwise.
 
I'm just never going to agree that pkg installing incompatible drivers is the right choice. If you need to frame that as user error in order to justify it for yourself then so be it. Good luck.
 
It doesn't "just install it", it warns you. If you use, as you said, cron, so you don't ever see the warning, that's not a problem with FreeBSD tooling. And I don't "frame" anything a user error, operating an EoL system and ignoring warnings is a user error.
 
Note that this drm change was documented in /usr/ports/UPDATING on May 1, 2022. But I guess most people don't update /usr/ports and even fewer look at the UPDATING file. There should be a way for the pkg program to warn the user of the latest UPDATING entries when they do "pkg update"....

While not ideal, you can checkout a local git repo of /usr/ports at the right commit and build the port yourself.
 
mer said:
I'm not going to argue against that, but it may break POLA.
Click to expand...
I agree that this breaks POLA - Principle Of Least Astonishment... ? It does take some thinking to realize that just patching up 13.0-RELEASE (IIRC, it's on p15) is not going to help.
 
  • Like
Reactions: mer
Things like this happen, then it affects enough people, and it gets fixed for most within a month.

It's good when things get eol'd, but if you're unsure of your environment, wait a while to upgrade packages/ports, and start fresh with that.

I'm glad some got obsoleted and replaced with a more standard one. However, I can't afford to mess with it now, even though I could. So, I'll wait a while to reinstall packages fresh. I could have been quiet about this, but to me, it does take a little work, and while it should work without a hitch. I usually can get it to work in about a day, on this, my guess is 75% with a little bit of effort on my behalf, or even 95% also including that and within a week after reporting/troubleshooting the error, but I don't want to mess with it now, because I have to focus on other things.

I also have this healthy fear of my only computer blowing out again, while trying to upgrade. I'm scared to do anything heavy with this laptop. Sure, I could get another harddrive, and put it in but still.

I may get criticism for saying this. But most people stay quiet, and I often troubleshoot, report bugs, write on the email list, or mention it here. I can't focus on fixing it if my upgrade from 54 to 510 goes wrong right now. The improvement of video drivers will be better for the near and longterm future.
 
  • Like
Reactions: mer
An interesting aspect is there is a large percentage of packages in the repo, built against 13.1 that work just fine on 13.0. But those are applications, not something like drm-kmod which by it's nature depends on the kernel version.
I've never been a fan of blindly doing binary upgrades, simply because I've been burned in the past when something got broken.
So, to me, my opinion, is running pkg upgrade automatically from a cron job is less than optimal.
If it was only checking for updates that's fine, but to automatically perform the upgrade is not a good idea.
That's why I still run pkg upgrade -n to see if there are updates, if so, I may simply up arrow, backspace, y Enter but sometimes I'll just update one or two packages instead of all of them.

But that's just my opinion, my procedures, my way of getting my "warm and fuzzies" and it may not work for you.
 
Well, in theory, package upgrades are safe.

In practice, there's a lot that can go wrong, from "forgetting" to upgrade your EoL base system ? to ports fucking up dependencies by human (err committer/maintainer) error resulting in removal of half your packages ... ?

mer fully agree, doing that via cron is not a great idea, unless, maybe, you're on a local repository that's only updated after testing everything on one test machine ....
 
  • Like
Reactions: mer
And once again a reasonable step would be to create a BE before upgrading so one can at least easily boot back into a running system while trying to figure out what went wrong and why if your system broke after any sort of upgrade rather than being stuck with a "broken" system.

The day I started using BEs was the day I stopped worrying too much about upgrades.

Yes, this requires ZFS but personally I feel like a lot of the discussion regarding the resource/performance impact of ZFS vs UFS are negilable for anyone who has to ask about this in the first place - especially given the advantages.
 
  • Like
Reactions: mer
zirias@ said:
Well, in theory, package upgrades are safe.
Click to expand...
"Until they aren't"

I've rarely had a problem with package upgrades. Most recent was the nvidia-driver equivalent of what this thread is about, but my pessimism/overly cautious method let me actually see the warning and told me how to get out of it. Other than that,there may have been a firefox upgrade that had minor breakage but was fixed very quickly.

I've also been very good about not staying on an EOL base. (I feel like I'm talking to my dogs: whose a good boy)

:eek:??

jbodenmann The day I started using BEs was the day I stopped worrying too much about upgrades.

Absolutely agree with this. I don't always create a new BE before doing a package upgrade, but "always" (or 99% of the time) create a new one before doing a freebsd-update.

It all boils down to your comfort level on doing things.
 
You must log in or register to reply here.
Back
Top