Discussion: FreeBSD 14.2-RELEASE Available

SirDice said:
/usr/ports/MOVED is used for input.
Click to expand...
Not really clear.

Let say, I have drm-61-kmod installed in 14.2-RELEASE and I don't use ports, I didn't even ever cloned them. Then, I upgrade to 14.3-RELEASE.
When I'll type pkg upgrade drm-61-kmod, how pkg will know which pkg name for replacing this one?
 
Emrion said:
When I'll type pkg upgrade drm-61-kmod, how pkg will know which pkg name for replacing this one?
Click to expand...
It won't. There's nothing to "upgrade" to. Package remains the same, same version, same code. Package name changes are recorded in /usr/ports/MOVED, which the package builders use for input. Then get recorded in the packages themselves. There's rarely anything manual that needs to be done, it typically just picks up those changes automagically. But we'll find out soon enough whether that's the case or not.
 
SirDice said:
It won't. There's nothing to "upgrade" to. Package remains the same, same version, same code. Package name changes are recorded in /usr/ports/MOVED, which the package builders use for input. Then get recorded in the packages themselves. There's rarely anything manual that needs to be done, it typically just picks up those changes automagically. But we'll find out soon enough whether that's the case or not.
Click to expand...
But in this specific commit, MOVED is not used, as the change is in version string.

I've looked into the changes a bit closely, and it is not enough for kmod issues.

As the name of pkg including version is, for example (stable/14),
before : drm-61-kmod-6.1.92_3
after : drm-61-kmod-6.1.92.1402501_3

This is because MOVED is untouched in this case, and means, pkgs for multiple releases (14.1, 14.2 and so on) cannot coexist in the same repository.

Why? Because if (to make it simpler, does not match current state)
drm-61-kmod-6.1.92.1401001_3 (for 14.1)
and
drm-61-kmod-6.1.92.1402001_3 (for 14.2)
coexists, the latter should be preferred even for 14.1 as its calcurated version is bigger, means, newer.
To support the coexistense, pkg(8) should be updated not to consider OSVERSION string (1401001, 1402001, 1402501,...) as the version of pkg file (detect and skip is needed).

Another option would be to expand architecture string of pkg from current
FreeBSD:14:amd64 (for all 14.*, amd64)
to something like
FreeBSD:1402:amd64 (specific to 14.2, amd64)
or
FreeBSD:1402001:amd64
for kmod ports. Or separate repository for kmod pkgs per-point-release.
 
T-Aoki said:
But in this specific commit, MOVED is not used, as the change is in version string.
Click to expand...
From the looks of it only the package name changes, the 'origin' (the port itself) remains the same. The 'origin' is recorded in the package itself.
 
Emrion said:
When I'll type pkg upgrade drm-61-kmod, how pkg will know which pkg name for replacing this one?
Click to expand...
SirDice said:
It won't. There's nothing to "upgrade" to. Package remains the same, same version, same code.
Click to expand...
I agree "Package remains the same, same version, same code", however that is for the source code. The upgrade isn't a "version" upgrade but it is an upgrade in binary code. You have a similar situation when doing pkg search drm-515-kmod on 13.3-RELEASE or on 14.1-RELEASE, you'll get the same version reported as a result, but you'll definitely get different binaries when you do a pkg install drm-515-kmod.

I don't think we can get a complete picture solely based upon commit kmod: append osversion to the portversion.

T-Aoki said:
Or separate repository for kmod pkgs per-point-release.
Click to expand...
I think they would want to avoid introducing such a new "per-point-release" repository/branch; instead they'll try to fit it into the existing repository structure, as you mentioned with:
T-Aoki said:
drm-61-kmod-6.1.92.1401001_3 (for 14.1)
and
drm-61-kmod-6.1.92.1402001_3 (for 14.2)
Click to expand...
and that indeed does require additional pkg logic.
 
Phishfry said:
Is vt(4) now feature complete with the old sysconsole?
Click to expand...
Unfortunately, no.
For example, screensavers worked on sc still doesn't work.
On the other hand, vt can display any characters included in UTF-8 encoding, if required fonts are loaded.
For example, if I load b16.fnt, I can read Japanese texts in UTF-8.
I have
allscreens_flags="-f /usr/share/vt/fonts/b16.fnt"
line in my /etc/rc.conf.
Note that input methods are completely different problem with vt.
 
Noticed one good thing with recent Mk/Uses/kmod.mk.
If
  • the computer itself or other computer in the same network is hosting local pkg repo, for example, built with poudriere
  • and (for local repo on local network, assuming all FreeBSD computers are running exactly same version/commit) FreeBSD running on the computer(s) is(are) not the oldest supported version of the branch (for example, 14.2 or recent enough stable/14),
  • and more, the local repo hosts not all pkgs used (prioritized configuration for repos),
  • and more, limited with kmod ports, all used are locally built,
no unmatched pkg for kmod ports are used.

Prioritized configuration can be done like below.
I put this as /usr/local/etc/pkg/repos/custom.conf, where /poudriere/data/packages/14amd64-default is the repo built by poudriere. This prioritizes local repo over official repo.

Code: 
custom: {
    url: "file:///poudriere/data/packages/14amd64-default",
    enabled: yes,
    priority: 100
}
 
You must log in or register to reply here.
Back
Top