On Sun, Nov 14, 2021 at 10:02:28PM +0100, Bálint Réczey wrote: > I believe when looking for a package to install the more popular ones > have higher probability to be the right fit. Currently 'apt search'
I don't think this is true. While w3m is on a downward trend for years it still easily outperforms every other browser in Debian (except firefox-esr of course): https://qa.debian.org/popcon-graph.php?packages=firefox%2Cfirefox-esr%2Ciceweasel%2Cchromium%2Cw3m%2Clynx%2Cmidori%2Ctorbrowser%2Clinks%2Clinks2%2Cluakit%2Cnetrik%2Ckonqueror%2Cdillo%2Celinks%2Cepiphany-browser&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 In the RFP bug you mentioned vim vs. emacs … you can actually argue with popcon that vim is far more popular – except for gtk people it seems: https://qa.debian.org/popcon-graph.php?packages=vim-gtk%2Cvim-gtk3%2Cemacs-gtk%2Cvim%2Cvim-nox%2Cemacs&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 And with that I come to another point: Desktop environment. For many users it is far more important to stick to an application which fits into their environment (be it due to aesthetics ala theme and such or usage/config paradigm) than how many people have installed apps from a 'competing' environment. Especially if that high number comes mostly from it being the default install. Being the default hopefully is the "best" choice, but it tends to be just the "most average for everyone" as the better choices are only for certain cases actually better. It isn't really working with "what is the best library to do X" either as due to the nature of how popcon works an old clunky library which never changes API/ABI performs way better than even the most hip and trendy alternative who fixed a trillion security bugs with API breaks. Beside that the sample is usually so small that the results could equally well be rolled by dice. So personally, I would consider this to give popcon far too much influence. It tends not to be the best metric for archive removals either. > results are sorted in alphabetical order, but a decreasing popularity > order would be more helpful, maybe even showing the percentage of > systems each binary package is installed on. It could certainly be a data point in a frontend specialist at browsing/ searching, but apt is not that frontend. It seems e.g. better to look at this from the "applications" level (aka Components) rather than from the "packages" level as a search for web browser on the packages level will always give you "bogus" results of the form "language pack for web browser foo" and stuff. Beside, firefox-esr is installed on less than 50% of the popcon participants (compared to dpkg) and that is the highest performer I mentioned. Not sure what 2.1% has vim-gtk, 2.2% vim-gtk3 installed is going to tell me usefully. And those are still rather popular packages compared to lets say the most popular strategy game (without looking, I would guess its wesnoth – but which version…). > At the moment the popularity data is not available, but I've filed > #999677 to solve that. If you agree with the proposal please share > your thoughts on the preferred database format in the RFP bug. Any data related to packages should be included in the repositories itself, popcon not really being an exception if you want to make use of that data even if many third-parties do not have comparable services. apt can be told to download additional data easily, apt-file and appstream e.g. do this. Might be best to show an existing prototype who picks the data off from a third-party repo to motivate debian archive judges^W^W^W ftpmasters to accept your dak patch (in the best case). Data format is traditionally deb822, json might be a contender, but given you will be high up the stack it doesn't really matter which parser you end up depending on. So, I think I would close this report as not going to happen (at least in apt itself), but perhaps others have a different opinion – we could then have a popularity contest to rank … (sorry, could not resist). Best regards David Kalnischkies
signature.asc
Description: PGP signature