broadcom-sta versioning is wrong

Issue #53 resolved
Rodrigo Bistolfi created an issue

We need packages for each kernel to coexist. Kernel version needs to be part of the name

Comments (10)

  1. Moises Henriquez

    The currrent setup is producing a package with the name broadcom-sta-6.30.223.248_3.18.16-x86-1vl71.txz where 6.30.223.248 is the VERSION value of the broadcom-sta package and 3.18.16 is the kernel version this module matches. Does this not work?

    We could maintain different builders if it suits the usecase better. ie, broadcom-sta3.18 for use with the 3.18 kernel and broadcomsta4.1 for use with the 4.1 kernel, etc.

  2. Rodrigo Bistolfi reporter

    I think it does not work, because the same broadcom-sta version for another kernel would be seen as an update by the package manager. I think the name of the package should be ${NAME}-${KERNEL_VERSION}-${VERSION} as you point out.

  3. roarde

    How do we get users who've already done --upgrade, and possibly upgraded kernel, back to the broadcom-sta, ndiswrapper, etc. packages they should have?

    If the kernel version is to be part of the kernel name, it will have to be the full kernel version, including the revision: broadcom-sta3.18.19, ndiswrapper4.1.5. The difference many times is only in what directory the module lands in, and the complete version is needed to specify that. Just as was done for today's (29 July) 3.18.19 rebuild.

    I prefer having the "extra" hyphen to separate the basename from the kernel-version part of the name, but our 'pkgname' is an antique and will be confused by that. There can't be a hyphen there for now.

    If I'm reading online info correctly, it looks like the code is now open source and in the kernel tree. Needs only to be enabled. If that's correct, wouldn't that be the way to go for 7.2?

  4. Moises Henriquez

    I pushed a test build to address this, but I feel I may have gotten it wrong. Can you post a sample of what the full package name should look like?

    Re: The source being in the kernel tree, we can definitely enable even for 7.1 new kernel builds. Can post which symbols(s) need to be enabled?

  5. roarde

    The build of July 30 would be the naming to use if you're going the one-name-per-kernel route.

    But why not include all kernel versions in a single package with the name "broadcom-sta" and the version "6.30.223.248". Do the same for similar packages, whether they're like broadcom-sta and need only to have the same file copied to a different module directory; or unlike it and need different compilation or dependencies for each kernel version. Yes, for those needing a build-per-kernel this would make the package build itself dependent on several kernel-sources or -module packages, but once successfully built it's easy to maintain and easy for users to follow in updates or patches. And all users would be fixed by the next --upgrade once the package is placed in patches/.

    Each time a kernel is added to the repos, bump the buildnum of each of these kernel-dependent packages and move it into patches/. If an actual new version of one of the packages appears; use the new version number, revert BUILDNUM to 1, and include versions for all kernels to date (for that VL version) in the initial package.

    No idea which symbols are needed for the broadcom kernel source; and many of the devices require firmware that's at kernel.org, but I know not where. Research is needed to do it correctly. Both that and maintaining consistency within 7.1 keep me recommending that the move to kernel-tree source be put off to 7.2.

  6. roarde

    A list of which packages are known to be affected by this issue would be helpful. broadcom-sta and ndiswrapper come to mind immediately, but there are more.

  7. Former user Account Deleted

    full package should be 6.30.223.248_$KERNEL and the old packages need to be purged.

    all of these are actually 6.30.223.248_4.0.5

    broadcom-sta-6.30.223.248_3.18.14-x86_64-1vl71 [inst=no]: broadcom-sta (Broadcom wireless drivers) broadcom-sta-6.30.223.248_3.18.16-x86_64-1vl71 [inst=no]: broadcom-sta (Broadcom wireless drivers) broadcom-sta-6.30.223.248_3.18.17-x86_64-1vl71 [inst=no]: broadcom-sta (Broadcom wireless drivers) broadcom-sta-6.30.223.248_4.0.5-x86_64-1vl71 [inst=no]: broadcom-sta (Broadcom wireless drivers)

  8. Moises Henriquez

    I think Rodrigo has a good point. Shipping this with the kernel itself I think is our best option.

    I did this in commit 8b5cec9 and it works quite well. It is packaged with the kernel-modules package. Not only this, but also other things that are dependent on specific versions of the kernel.

  9. Log in to comment