Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#64840 - [nvidia] package should explicitly depend on associated kernel version

Attached to Project: Arch Linux
Opened by Peter Fern (pdf) - Saturday, 14 December 2019, 20:28 GMT
Last edited by Sven-Hendrik Haase (Svenstaro) - Saturday, 15 February 2020, 23:40 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Sven-Hendrik Haase (Svenstaro)
Giancarlo Razzolini (grazzolini)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description: Since the package can only ever work for a specific kernel version, shouldn't that constraint be added to the package dependencies? This should be automatable, and would avoid issues like  FS#64832   FS#56449   FS#63292  (and more I suspect).
This task depends upon

Closed by  Sven-Hendrik Haase (Svenstaro)
Saturday, 15 February 2020, 23:40 GMT
Reason for closing:  Deferred
Additional comments about closing:  See comments.
Comment by loqs (loqs) - Saturday, 14 December 2019, 21:16 GMT
 FS#56449  and  FS#63292  were closed as invalid.
Comment by Sven-Hendrik Haase (Svenstaro) - Sunday, 15 December 2019, 16:42 GMT
@grazzolini: Thoughts?
Comment by Eli Schwartz (eschwartz) - Monday, 16 December 2019, 14:13 GMT
Thoughts:

- Partial updates are unsupported.
- The world is filled with archlinux packages which don't "explicitly depend on associated XXXX version".
- It is not as easy to automate as the OP thinks, except by hardcoding the version in the PKGBUILD. makepkg doesn't have a grammar for this.
Comment by Giancarlo Razzolini (grazzolini) - Monday, 16 December 2019, 14:29 GMT
I also think that tagging specific kernel versions is not ideal. Also, it doesn't really help with the issues, because it would make it *easier* to make human errors, not harder. If the OP really wants not to need to worry about kernel versions, we provide the dkms version already.
Comment by Peter Fern (pdf) - Monday, 16 December 2019, 14:35 GMT
Whilst policy may be that partial upgrades are not supported, they're also not avoidable by end users, and depend on the state of the repo at the time a user performs an upgrade. If the world is filled with packages that exhibit such problems, and they result in significantly non-functional systems for users, surely that's more incentive to examine the problem?

It sounds like the objections are largely based on lack of support from the tooling to automate the process, should an issue then be raised against makepkg, and if so, any thoughts on what that would look like, or how it ought to function?
Comment by Trygve Aaberge (trygveaa) - Monday, 16 December 2019, 14:41 GMT
> Partial updates are unsupported.

Yes, but having this constrain would be helpful when downgrading to debug issues such as https://bugs.archlinux.org/task/64847#comment184583
Comment by Giancarlo Razzolini (grazzolini) - Monday, 16 December 2019, 14:41 GMT
@Peter,

The nvidia package usually is moved at the same time as the kernel is upgraded. So, a partial upgrade because of a bad repo should happen on very rarely occasions. Also, a subsequently pacman -Syu fixes the situation.

I'm not sure exactly how you could accomplish such automation on makepkg, without querying the repos and, still, I see it having issues. Requiring the maintainer to having to update more fields on the PKGBUILD makes it *more* error prone, not less. Also, the nvidia packages goes to [testing] where we usually spot these errors. I myself have rebuilt the nvidia package twice when I've spotted kernel mismatch.
Comment by Giancarlo Razzolini (grazzolini) - Monday, 16 December 2019, 14:47 GMT
@Trygve

We have nvidia packages for the linux and linux-lts kernel. We have two other official kernels that don't have a package: linux-zen and linux-hardened. You need to use -dkms for both. Also, for debugging and downgrading, you can/should also use -dkms. I don't see the issue in doing that.
Comment by Peter Fern (pdf) - Monday, 16 December 2019, 14:47 GMT
In terms of automating the metadata in makepkg, I would imagine some sort of meta tag that would be handled by during build process, rather than hand-modifying anything.

Honestly, the optimal solution for these sorts of issues would be a mechanism to allow multiple versions of a package to be installed at the same time, as many other distros handle kernel upgrades, but discussions on this option in the past seem to have gone nowhere.
Comment by Eli Schwartz (eschwartz) - Monday, 16 December 2019, 14:52 GMT
The state of the repo is supposed to be consistent at all times, having broken packages is a serious bug on our part.
You've pointed to 3 bug reports, of which, two of them were invalid. In the third case, the nvidia rebuild was moved to extra a couple hours before the new kernel was, which, I don't know why, but on the other hand that is indeed a serious bug.

The consequence of this failing is that the repos are broken, and pinning a kernel version won't solve that.

So your assertion that this is "not avoidable by end users", is really a very simple case of *one time* that you can point to a broken package being released to the repos, which needed to be fixed regardless of whether explicit version dependencies were added.

...

> It sounds like the objections are largely based on lack of support from the tooling to automate the process, should an issue then be raised against makepkg, and if so, any thoughts on what that would look like, or how it ought to function?

No, the objections are largely based on it's not actually attempting to solve the problem, and the only effect such a change would have is to make pacman -Syu return a fatal error while refusing to continue.

The fact that makepkg doesn't have tooling for it is simply my observation that your proposal that it can be automated is factually incorrect, regardless of whether I think it should be or not.
Comment by Eli Schwartz (eschwartz) - Monday, 16 December 2019, 14:58 GMT
Please note that regardless of my opinion on this bug, I do consider such automation to be an interesting thought experiment, plus pacman is intended to be a generic package manager, not archlinux-exclusive... I have explored this thought in https://git.archlinux.org/users/eschwartz/pacman.git/commit/?h=autoversioned-dependencies&id=ef669b57618b53c853988db53fe38e27be56919b

But it's a gnarly problem, my thought experiment is currently only in the beginning stages, and I'm not yet 100% convinced it should become official.
Comment by Peter Fern (pdf) - Monday, 16 December 2019, 14:59 GMT
The other reports were marked as invalid because 'partial upgrades are not supported', however they occurred (at least two of the three cases I can personally confirm) due to inconsistent repo state.

Having pacman fail early, rather than producing a broken system for users to try and diagnose (and fix without GUI access, especially problematic if, e.g. only on WIFI) is a *preferable* outcome IMO.
Comment by Peter Fern (pdf) - Monday, 16 December 2019, 15:05 GMT
I've got to get some sleep, but that thought experiment aligns roughly with what I imagined.
Comment by Trygve Aaberge (trygveaa) - Monday, 16 December 2019, 20:31 GMT
@Giancarlo: My point wasn't how to get the correct version of the driver. If you run the normal kernel and downgrade, you don't need dkms, you can just downgrade the nvidia package as well. My point is that if you run into a bug where you need to downgrade the kernel (such as the one I linked to), you might not remember or think of that you need to downgrade the nvidia driver as well. With a version specific package, pacman will tell you that right away, so you don't reboot into an installation without the graphics working.

Probably not a huge deal, but it is one instance where a versioned dependency would be helpful.
Comment by Giancarlo Razzolini (grazzolini) - Monday, 13 January 2020, 13:08 GMT
@Trygve

I think that we already provide -dkms for that. Also, adding versioning is only going to give the kernel maintainers and the nvidia package maintainers more work for no real good reason. We get that breakage can happen due to wrong packaging, but we try to get that on [testing] before it hits the repos. Not guaranteed, but I've catch at least two times breakage before it hit the repos.

Perhaps, if/when we get automated builds, we can improve the situation. I would say we close this bug for now.

Loading...