Link to the reason if a package is not available for an arch #384
Comments
|
Do you have an example URL please? |
|
@grahamperrin explains it here. Unfortunately the URL scheme does not appear to be super easy. Looks like the code in question is in https://github.com/bdrewery/pkg-status.freebsd.org, @bdrewery: maybe some APIs could be made for retrieving this kind of information? |
|
Maybe link to https://portsfallout.com/port?port=^print/hplip$ (although it doesn't show any failure at the moment, even though the package is missing; @dbaio do you know why?) |
|
Cross-reference: http://beefy18.nyi.freebsd.org/build.html?mastername=main-amd64-default&build=p47ff75a1891e_s2c2ef670a7
|
|
The portsfallout.out links where added via #181 about two years ago. The link is at the top of each port page, just to the right of |
|
What I mean is to put a link into the otherwise empty boxes, maybe somewhat like this:
But Fallout would have to become a bit more intelligent, so that it would tell us that |
From https://portsfallout.com/about:
https://github.com/dbaio/portsfallout#readme This month's archived e-mails about https://lists.freebsd.org/ there's nothing like a list for skipped ports. |
Based on that: nothing more to do here. |
Re: <FreshPorts#384 (comment)> it's not possible to distinguish between fallout and a skip, so offer an explanation for there being no fallout in response to a click on the fallout icon.
@dlangille please, it is possible for each single fallout icon to appear only if the user points at the cell? Maybe an empty cell until pointed at, although (second screenshot below) the previously used dash/hyphen was also effective as a hint. RationaleThe masses of hazardous fallout (non-availability) sometimes detract from what's of greater interest to the majority of users:
Compare, for example:
– with this, from a Wayback Machine capture a few months ago:
|
|
Agree, a "hover" showing the icon only when the mouse is in the cell would also do the job. |
|
These changes are now on test, but not the hover issue mentioned above. Please review them and see if they are OK. Then I'll tackle the hover. |
Details1. 2. for quarterly 3. `firebird30-client-3.0.7_2` amongst the failures 4. open _coredump_ in a new background tab 5. under _origin_, open _databases/firebird30-client_ 6. edit `www` to `test` then add `#packages` to the tail of `https://test.freshports.org/databases/firebird30-client/` 7. atThe two are effectively the same:
– and at https://lists.freebsd.org/archives/freebsd-pkg-fallout/2022-October/date.html by date for this month, the penultimate match for 131amd64-quarterly][databases/firebird30-client] Failed for firebird30-client is https://lists.freebsd.org/archives/freebsd-pkg-fallout/2022-October/279283.html, Sun, 09 Oct 2022 01:34:57 UTC. Test result: OK. However … |
UX… at https://test.freshports.org/databases/firebird30-client/#packages there's an implicit requirement to pay careful attention to the build date, if the end user is to identify the correct log file. Let's be realistic about the likelihood of users actually paying attention and then knowing what to do with the date. What's most obvious (uppermost) at the fallout list might be not an explanation for a gap in the table of packages at FreshPorts. With the databases/firebird30-client example above, at the time of writing there's a parallel build at https://pkg-status.freebsd.org/beefy14/ in progress (neither done, nor crashed), it's this build that produced the log for 131amd64-quarterly that's currently uppermost at the fallout list. |
|
https://test.freshports.org/graphics/py-cairo/ now has 275 fallout links to a single page that confirms, no fallout. For a port that truly does have fallout: https://test.freshports.org/databases/firebird30-client/#packages in theory, you might customise each fallout cell within the table, to precisely directly link to the historic reason for fallout (or skip) at that point in time. In reality, for now, the more that I think about this, the general direction to the (one) fallout page for a port is better served by the (one) existing fallout icon that's already at the head of production service (www). Sorry … that's not intended to be defeatist. Just realistic about what's gained if multiple fallout links to a single page are added. (Am I missing something?) |
When I start reading this, I wonder: what is this list? Why should I look at this link? Holy shit, I have a lot to review here. What? Then I read:
OK, no action required here. Phew. |
My interpretation: No action required. |
How would that be done? For background, the lists which appear under Packages are meant to be a list of what you can download now. Every hour, at the top of the hour, the package repos are queried to see if there are any new builds available. The How does the code detect the right link to provide?
The whole point of this issue was a link to the fallout page. They are all identical links right now. I'm happy to provide more specific links - perhaps getting the ABI values involved... |
Yeah, I did want to use |
Oh, that'll be smart, if it's possible. (I imagined it not possible. Sorry.) |
I have not imagined how to do it. I will leave that to someone with more time. :) |
I frequently find myself wondering why certain packages are not available for certain archs.
It would be enormously helpful if instead of showing empty boxes on
https://www.freshports.org/print/hplip
these empty boxes would contain links to
instead so that one could know why the package is not available for this arch.
Reference:
The text was updated successfully, but these errors were encountered: