Hi, On 06-01-2024 08:21, Johannes Schauer Marin Rodrigues wrote:
I think it's a bit more complicated than that. Currently, the tool creates 8624 package relationships. If I remember correctly, britney is unable to analyze cross-architecture relationships?
At least by lack of implementation. But thinking about pure cross-architecture relations (I mean those that are *only* satisfied using multiple architectures) a bit, what is it that we'd want at the archive level? I guess there are exceptions we could accept like from src:steam-installer (which doesn't use :i386 or :amd64 at the moment if I'm correct) or src:wine (which only uses it in alternatives and IIUC could equally well use :any), but do we really want to allow pure cross-architecture relations in general? I don't think so. What kind of complexity would that add for architecture qualification and efforts to remove an architecture from the archive later on? (steam-installer if it were using architecture qualifiers now would probably be handled somewhat because it could be accepted once manually and then afterwards it's accepted by britney2 because the non-installability doesn't go up).
In that case that number goes down to 2352. One could reduce that number even further and only check those cases where apt, dpkg and dose3 agree on a solution but that would then rather be a documentation of the status quo than a list of the intended ground truth. Maybe it would make sense to analyze the archive and only add those cases that currently exist as real package relationships?
As far as I can tell (I checked testing/main/source, testing/main/(amd64|i386) and testing/contrib/(amd64|i386) for (:i386|:amd64)) there is no package that does this for Depends or Build-Depends (excluding alternatives in src:wine and src:build-essential). So I think we can reduce it to :any in Depends and :any and :native in Build-Depends. Not sure how far your number goes down then.
What the tool never received since its inception was somebody to look over these cases and write down what the ground-truth actually is supposed to look like. For the britney tests you likely want some kind of ground-truth and I fear that tool can give you the status quo but not necessarily the truth as intended by the spec.
Ack.
If that is fine for you, do you still want to add thousands of test-cases? Or do you want to hand-pick them?
It depends on the route we take and what we envision as useful cases to support. What I want to avoid is two things, highest prio first:
1) something that we don't want to migrate migrates (I think the current *lack* of support achieves that mostly already) albeit *maybe* my current fix for this bug is going to change that unintentionally in the wrong direction.
2) (lots of) packages being blocked for useful use cases (that we could hint through, but that britney2 would consider non-installable, so not protected from then on) I think this bug report is one of only a couple over the years that requested anything on this front (I think all were from Simon), so I wonder how many (legitimate) use cases there are that people would want to use and don't because of lack of support on our side.
Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature
