Bug#238687: popularity-contest: popularity contest should provide subarch info.

2024-01-14 Thread Bill Allombert
On Sat, Jan 13, 2024 at 12:51:47PM -0800, Matt Taggart wrote:
> It's been quite a while since this bug was discussed, but I have another use
> case where it might be interesting...
> 
> There has been some recent discussion about "Architecture Variants" and in
> particular amd64 variants. Fedora and Ubuntu are both working on experiments
> with the goal of being able to optimize for newer versions of the amd64
> architecture (and potentially dropping older variants at some point as
> well). Here is a page that gathers info on this idea for Debian
> 
> https://wiki.debian.org/ArchitectureVariants
> 
> Knowing information about which variants our installed base is using would
> help make these decisions easier. The past i386 decisions were a little
> easier because there were particular packages we could look at to get those
> numbers.

Hello Matt, thanks for reviving this bug.

Note that unfortunately, none of the requirement I set up in the my previous
answer to this bug have been addressed.
In particular, there is no official definition of subarchitecture and tool
that report it that popcon could use.

However, I doubt the practicality of reporting subarchitectures:
1/ users might not be running the latest Debian release, and there is no way to 
know
if they plan to upgrade.
2/ the number of users running some subarchitectures is likely to be very small,
which breaks anonymity.

Cheers,
Bill



Bug#238687: popularity-contest: popularity contest should provide subarch info.

2024-01-13 Thread Matt Taggart
It's been quite a while since this bug was discussed, but I have another 
use case where it might be interesting...


There has been some recent discussion about "Architecture Variants" and 
in particular amd64 variants. Fedora and Ubuntu are both working on 
experiments with the goal of being able to optimize for newer versions 
of the amd64 architecture (and potentially dropping older variants at 
some point as well). Here is a page that gathers info on this idea for 
Debian


https://wiki.debian.org/ArchitectureVariants

Knowing information about which variants our installed base is using 
would help make these decisions easier. The past i386 decisions were a 
little easier because there were particular packages we could look at to 
get those numbers.


Side note
In addition to this bug, it seems there are some other cases where 
people would like to press popcon into service to gather other things:


kernel modules
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=202675

report arch only
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545000

report foreign architectures
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931764

Package versions
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=97045

aptitude auto flag
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=313194

package config file data
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816281

We can understand why it is tempting to want to do so. But there are 
also privacy and scope implications. So maybe the first step is a clear 
policy of what is appropriate for popcon to do, and the things that 
aren't should be WONTFIX.


Thanks,

--
Matt Taggart
m...@lackof.org