Bug 389715 - Parse and reformat ugly strings that PackageKit gives us for Debian-based repos
Summary: Parse and reformat ugly strings that PackageKit gives us for Debian-based repos
Alias: None
Product: Discover
Classification: Unclassified
Component: discover (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: Aleix Pol
: 389648 (view as bug list)
Depends on:
Reported: 2018-01-31 18:49 UTC by Nate Graham
Modified: 2018-02-09 18:07 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:

Can't distinguish source repos from binary repos (117.78 KB, image/png)
2018-02-01 17:24 UTC, Nate Graham

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2018-01-31 18:49:34 UTC
PackageKit currently gives us ugly strings for debian-based repos that look like this: "/etc/apt/sources.list.d/neon.list:deb http://archive.neon.kde.org/dev/unstable xenial-main"

This produces unreadable list items on the Settings page. It sucks, but in the interest of usability and reasability for all our Debian- and Ubuntu-based users (Including KDE Neon users!), we should reformat these ugly strings to look more like this:

xenial main (neon.org)
xenial main sources (neon.org)
restricted universe multiverse (neon.org)
restricted universe multiverse sources (neon.org)

The above is still mostly technical gibberish, but at least it will be readable.
Comment 1 Nate Graham 2018-01-31 18:56:27 UTC
*** Bug 389648 has been marked as a duplicate of this bug. ***
Comment 2 Aleix Pol 2018-02-01 16:01:42 UTC
Git commit 3243f99b75ecebbc2bfa59b42de3b024eca4e3a2 by Aleix Pol.
Committed on 01/02/2018 at 15:10.
Pushed by apol into branch 'Plasma/5.12'.

Make it possible for the source id to be different from the display string

M  +2    -1    discover/qml/SourcesPage.qml
M  +1    -1    libdiscover/backends/FlatpakBackend/FlatpakSourcesBackend.cpp
M  +3    -10   libdiscover/backends/PackageKitBackend/PackageKitSourcesBackend.cpp
M  +2    -1    libdiscover/resources/AbstractSourcesBackend.h
M  +1    -0    libdiscover/resources/SourcesModel.cpp
M  +3    -3    libdiscover/resources/SourcesModel.h

Comment 3 Aleix Pol 2018-02-01 16:15:41 UTC
Git commit e8df9489c89b491c3eea3a88c10760376257322e by Aleix Pol.
Committed on 01/02/2018 at 16:13.
Pushed by apol into branch 'Plasma/5.12'.

Only show the description for PackageKit sources

The id looks mental

M  +1    -1    libdiscover/backends/PackageKitBackend/PackageKitSourcesBackend.cpp

Comment 4 Nate Graham 2018-02-01 17:24:35 UTC
Created attachment 110288 [details]
Can't distinguish source repos from binary repos

This is great! There's only one issue: the source repos now look the same as the binary repos. The actual strings are:

$ cat /etc/apt/sources.list.d/neon.list 
deb http://archive.neon.kde.org/dev/unstable xenial main
deb-src http://archive.neon.kde.org/dev/unstable xenial main

But they both show up as "Xenial (main)" See attached screenshot.

I would recommend adding the word "sources", so we would have the following:

Xenial (main)
Xenial sources (main)

Bonus points if there's a way to always show the source repos second.
Comment 5 Aleix Pol 2018-02-01 17:33:06 UTC
Regarding the "sources" part, this needs to be reported to PackageKit ideally.

Regarding sources after, we can keep the list sorted, so it will always be the same?
Comment 6 Nate Graham 2018-02-01 17:38:20 UTC
Sounds good.

If we can possible differentiate the source repo ourselves, I think we should try, but if we can't, then making a request to the PackageKit guys could make sense. It would make more sense for you to handle that since you have a pre-existing relationship with them and know exactly what to ask for (also maybe they'll be in a charitable mood since you just fixed the ODRS bug!)
Comment 7 Nate Graham 2018-02-09 14:43:29 UTC
You submitted a PR for PackageKit, yay! https://github.com/hughsie/PackageKit/pull/238

Will this fix itself for free once that's in, or will we still have to do any further string manipulation ourselves?
Comment 8 Aleix Pol 2018-02-09 17:42:45 UTC
No, when PackageKit is fixed it will be fixed here too.
Comment 9 Nate Graham 2018-02-09 18:07:48 UTC
OK, marking as RESOLVED UPSTREAM then (since it's 100% upstream's responsibility at this point).