On 2019-11-02 19:31, Glen Barber wrote:
On Sat, Nov 02, 2019 at 12:14:05PM -0600, Warner Losh wrote:
On Sat, Nov 2, 2019 at 10:20 AM Glen Barber <g...@freebsd.org> wrote:
On Sat, Nov 02, 2019 at 02:12:50PM +0000, Sergey A. Osokin wrote:
On Fri, Nov 01, 2019 at 02:52:50PM +0000, Glen Barber wrote:
On Fri, Nov 01, 2019 at 01:44:18PM +0000, Sergey A. Osokin wrote:
At the moment we have graphics/drm-fbsd12.0-kmod port for 12.0.
I hope in most cases it's enough for RELENG_12 branch, however
just to avoid a potential confusion I see the following options
we can do:
- create a new port for 12.1 only
- rename the existing port to drm-fbsd12-kmod
- rename the existing port to drm-fbsd12.1-kmod (in case of 12.0 EoL)
What about using the meta-port and keying off of OSVERSION?
(Personally
I have no real preference either way, nor with any of the solutions you
propose above.)
Actually we have one, graphics/drm-kmod, and it depends on the following
one:
.elif ${OSVERSION} >= 1200058 && ${OSVERSION} < 1300000
RUN_DEPENDS= ${KMODDIR}/drm.ko:graphics/drm-fbsd12.0-kmod
...
So, in case we don't expect an API/ABI changes in 12.x branch we can
just rename it to drm-fbsd12-kmod, or create a specific version of
the port for 12.1 - drm-fbsd12.1-kmod and update the meta-port as well.
We should never expect this type of ABI/KBI breakage along a stable
branch. (That is our definition of "stable", technically, but sometimes
there are unexpected breakages that occasionally go undetected.)
The KPIs that drm depends on are quite specific and weird and aren't part
of the set we guarantee (and we can't do what drm needs to do with only the
'safe' ones). It's not much different than virtual box which also has this
issue frequently because it too falls into that category.
Agreed. (FWIW, I specifically made sure the virtualbox-ose-additions
did not cause system crashes for 12.1.)
Also, since this is repeatable thing for every upcoming release
we can add this point to the check list and release scheduling.
Yes, good idea. Just let us know how you want to proceed, and we can
add a note to the documentation.
I mean I believe we should that (create a new port, update the meta-port,
etc.) in advance, in the beginning of the first phase of release cycle.
This seems like a reasonable approach.
How do we get packages from the new port into the release so that users
don't install the 12.0 port by mistake?
It just needs to be merged to the 2019Q4 ports branch. For the package
available on the dvd, it is unfortunately too late, but only the
graphics/drm-legacy-kmod and graphics/drm-stable-kmod packages are on
the dvd by default anyway. In other words, the meta-port is not
included, but once a commit is merged to the 2019Q4 branch and the
upstream binary packages are rebuilt, they will be available by default.
Please note that just creating a separate package for FreeBSD 12.1 (in
this case) does not solve the issue. drm-fbsd12.0-kmod builds and works
fine on FreeBSD 12.1, the issue is that the version built on 12.0 does
not work on 12.1.
Since packages for 12.1 are built on 12.0, just having a separate
package would not work in any case.
Regards
--
Niclas Zeising
FreeBSD Graphics Team
_______________________________________________
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
