Arch Linux

 FS#56449  and  FS#63292  were closed as invalid.

@grazzolini: Thoughts?

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.

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.

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?

> 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

@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.

@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.

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.

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.

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.

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.

I've got to get some sleep, but that thought experiment aligns roughly with what I imagined.

@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.

@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.