> Which pages is it supposed to replace? What is the relation to
> https://src.fedoraproject.org/rpms/?
>
It is unrelated to src.fedoraproject.org. This is replacing the former
https://apps.fedoraproject.org/packages/. It was taken down permanently
during the datacenter move.
> Some initial comments:
> - the search results page seems … messy. Would it be possible to
> group results by parent package? E.g.
> https://packages.stg.fedoraproject.org/search?query=systemd returns
> four pages of results, and a large number of entries is for
> subpackages. Grouping them would make it easier to find other
> interesting packages which are not part of the main package.
>
There seems to be a method to group things in Solr. The results are
likely bloated because the query parser defaults to OR-ing multiple
terms rather than dnf's default AND. I think that increasing the amount
of results and using the shorter description should also make results
more compact.
> Maybe also sort the results somehow? I think the method that dnf
> uses is pretty good: result are grouped by how they are matched:
> "Name Exactly Matched", "Name & Summary Matched", "Name
> Matched",
> "Summary Matched". And within each group, results are sorted
> alphabetically. This gives a "clean" look (also because subpackages
> tend to be grouped together), gives the most relevant result first,
> and still makes it easy to scan the list.
>
I think that this specifically is not possible without hacking together
multiple queries. This would be better accomplished through changing the
search rankings via reranking or using the DisMax query parser on the
package descriptions and names with appropriate weighting.
> - A search result for a subpackage links to a page for that subpackage.
> That's more confusing than useful:
> https://packages.stg.fedoraproject.org/pkgs/systemd-networkd/ shows
> the description for systemd-networkd, but all the information is
actually
> for systemd source package.
>
> I think linking to a single page named after the source package
> would be more useful to users. Subpackages should be listed on this
> page. This is how Debian/Ubuntu to it. (It would also seem quite
> natural if the results were grouped by source package, as suggested
> above.) [EDIT: Oh, I see that this is done to an extent, the main
> package has "Subpackages" section. Unfortunately this doesn't take
> into account that different Fedora releases can have different sets
> of subpackages. This information is very important to users too.]
>
I disagree here. systemd-networkd's metadata is significantly different
from other subpackages for that source package. For example, the
descriptions, provides, requires, and files (some of which is only
visible after clicking a version number) for each subpackage are
completely different. In some cases, such as texlive, even the versions
for each subpackage differ. Clobbering all of this information into one
page would be confusing for large source packages such as glibc. Every
single subpackage would have to be enumerated along with a version table
and description, completely hiding the recent activity section.
Additionally, it doesn't make sense to return something completely
different that what the user asked for. E.g. if I lookup
systemd-networkd, I should retrieve information only for that specific
subpackage rather than show a list of all related subpackages. From the
point of view of someone who does not understand how packages are built,
this behavior would be extremely confusing. This is also the case with
Debian from my understanding? You can search for a package in a specific
release and the source package is only linked at the top left as an index.
I think the takeaway here is that everything needs to be grouped by
source packages as you said. My actions on this will probably be:
- Change urls to /pkgs/<source pkg>/<subpackage>
- /pkgs/<source pkg> should become an index listing subpackages similar
to suggested
- /pkgs/<source pkg>/<subpackage> will contain the current subpackage pages
- Subpackages pages will contain a "Related Packages" section that links
to other subpackages for a source package
- If a subpackage matches the name of the source package, it is treated
as the "primary" subpackage
Different releases are taken into account to my understanding. E.g.
systemd-oomd-defaults only lists versions for F34 and rawhide whereas
the systemd package lists more releases. I plan to introduce filtering
in search based on what version of Fedora a package is available for.
> - Related to the above: source package names are unique. Binary package
> names are also unique for any given release of Fedora/EPEL/ELN/etc,
> but not unique globally. There's an epel-only systemd-extras source
package
> which also builds systemd-networkd binary subpackage. But right
> now the name is "occupied" by one of the subpackages, and no
information
> is shown for the other one. It would be even worse if there was an
> epel-only systemd-networkd source package, because the main package
> couldn't be shown at all.
>
> Putting both binary and source packages under the same prefix
> https://packages.stg.fedoraproject.org/pkgs/ cannot work.
>
Above plans should resolve this.
> - Are the descriptions takes from some old release? For systemd I see
> "built from the 245.4-stable branch of systemd" while even f32 has
> 245.9 now.
>
Descriptions should be taken from rawhide metadata. I will look into
what is happening there.
> - Whitespace in descriptions is squished. E.g.
> https://packages.stg.fedoraproject.org/pkgs/systemd-swap/ looks very
> strange. Generally package descriptions are supposed to be preformatted
> text that fits in 80 columns. I don't think it should be wrapped at
all.
> 'dnf info systemd-swap' looks good;
> https://src.fedoraproject.org/rpms/systemd-swap does a reasonable job,
> except that it centers everything;
> https://packages.stg.fedoraproject.org/pkgs/systemd-swap/ is hard to
> read.
>
I will have it respect line breaks to resolve this, I would rather not
use preformatted text for smaller devices like phones.
> - There's "Recent Activity" at the bottom. For some packages this works,
> but for others it only shows "Loading…". I see "TypeError: NetworkError
> when attempting to fetch resource" shown for a fraction of a second.
That's a bug, I need to have it listen for when the browser starts to
navigate away and gracefully cancel that http request.
> - "SCM" links to a page that calls itself "fedora PACKAGE SOURCES"
> and
> that everybody seems to refer to as "dist-git" or "pagure" in
> conversations. Maybe it would be better to call the link "sources"
> or "dist-git source" or "package source"?
>
> (And "FAF" links to "retrace.fedoraproject.org" page that calls
> itself
> "ABRT Analytics". I don't even know what to suggest here ;| .)
"FAF" (Fedora Analysis Framework) is the old name for ABRT Analytics to
my understanding. I have been leaning towards just renaming all of those
links to generic names such as "Problems" or "Crash Reports" as you have
suggested. Anyone who isn't a packager wouldn't understand what "Koji"
and "Bodhi" are.
> - https://packages.stg.fedoraproject.org/pkgs/systemd-swap/ has a number
> of broken images in the "Recent Activity" part. Since that's generated
> content, it's not so easy to see what's going on…
The image URLs are pulled from datagrepper, I need to go and fix those
upstream.
> I hope that's useful feedback. Thanks for working on this!
I appreciate this, it is very detailed and exactly what I was looking for!
Brendan Early
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
