On Thu, Aug 13, 2020 at 2:01 PM Aaron Puchert
Am 13.08.20 um 01:25 schrieb Neal Gompa:
The thing is, based on the conversations earlier, it seems like there is no way for openSUSE to support treating ARM, POWER, or RISC-V at the same level as x86. It's been indicated that there's not enough hardware resources to plug into the staging workflow, and the alternative architectures break too much to be included in openSUSE:Factory, and nobody wants to make it mandatory for builds to pass on these architectures before releasing snapshots.
You're right that there is a long way to go from ports to where x86 is right now. But maybe there are some intermediate steps.
Technically I see no reason to couple the releases of snapshots for different architectures, you could reasonable decide to ship a snapshot for x86 only and skip it for aarch64.
Alternatively, you could stage updates separately in bigger batches, hoping that x86 staging already catches most issues and you'll only see ARM-specific issues in the second staging. Then aarch64 would lag behind, but maybe not too much.
So we have a few choices:
1) Include aarch64 in Factory staging, which needs more hardware (maybe) and could end up blocking x86 updates unreasonably. 2) Accept that Factory:ARM can sometimes be broken and we can't release snapshots for it. Can we get it back to releasable state quickly enough until the next issue appears? If not, then you're right. 3) Let Factory and Factory:ARM be separate repos and have a staging workflow Factory -> Factory:ARM. Then both repos could diverge, but Factory:ARM should be releasable most of the time.
With 1) we would be on par with x86, with 2) and 3) slightly behind, so there would be three tiers then. Still, it might be a good first step.
My experience has indicated that unless you make alternate architectures everyone's problem, it's just *not* going to get any better. For example, Fedora has x86_64, AArch64, and armv7hl as primary architectures, with ppc64le and s390x as secondary architectures. But for packagers, they are all effectively primary architectures because the build system will not let a build through without it successfully building for all architectures that it is supposed to be built for. openSUSE's problem is that they don't want to take that step to make their alternate architectures actually regularly useful by *forcing* every architecture into openSUSE:Factory. There has been no proposal from Dirk or anyone that even reasonably considers eliminating the "ports" tree. This is even sillier when you realize that SUSE Linux Enterprise doesn't bother with this malarkey and actually *does* force all architectures into the same development project because they know in order to make it supportable, they have to have a consistent tree for all architectures. Otherwise the "common codebase" is a lie.
This is still possible with DNF, it just doesn't do it interactively. It will just fail and print out all the solver errors at once. You can use all those errors to adjust the transaction accordingly.
You can also tell DNF to attempt to remove problematic packages all at once and attempt to resolve the transaction accordingly with "--allowerasing"
The only thing we don't have in DNF right now is an equivalent of "zypper install foo -bar -baz" and "zypper remove +foo bar baz" (which do the same thing). There is "dnf swap bar foo", though.
And there's the dnf shell to do more complex transactions...
I see. Well, some people like it more interactive and some want to automate. I don't think either is necessarily wrong, and if you have a lot of time you might just allow both.
[...] or leads to a broken system...
That would be strange, because requirements are still checked.
The point of this is to let you *ignore* dependencies and explicitly break them. It was actually an early design goal that DNF does *not* include this functionality because people often used it to subtly break their systems with less-than-obvious ill effects.
Maybe it's worth revisiting this, but I'm not sure it is...
Now I get what you meant. I admit that I've done this sometimes because requirements for packages were too strong. (Eventually I started filing SRs afterwards to make it a Recommends: or something like that.)
It's a somewhat questionable feature, but sometimes it's good to have the "I know what I'm doing" mode. And you can still unbreak your system with "zypper verify". But maybe it needs to be more difficult so that users don't accidentally end up there.
My belief is that this feature has actually made it easier to ignore fixing dependency issues in openSUSE projects. I think not having it would be a good way to force fixing these kinds of problems, since you have no other recourse but to play nice. -- 真実はいつも一つ!/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org