- Package:
- popularity-contest
- Source:
- popularity-contest
- Submitter:
- Sven Luther
- Date:
- 2024-01-14 14:00:02 UTC
- Severity:
- wishlist
popularity contest should provide info about the subarch, maybe using the same code as d-i archdetect. Friendly, Sven Luther
[Sven Luther] Interesting idea, and it should not be too hard to implement if the information is available within a debian system. Is there an installable debian package providing such information? The d-i package is only an udeb, and thus not available for popcon.
Hi, to decide what subarchitectures should be supported in future releases, it would really be helpful to see which are in current use. So I suggest something like the following patch. It only determines this information for Alpha, since I'm not sure how to get it for other architectures, and in particular, which categories would be relevant. Opinions?--- popularity-contest~ 2005-07-18 08:15:52.000000000 +0200 +++ popularity-contest 2005-10-08 17:24:52.000000000 +0200 @@ -57,7 +57,25 @@ # Architecture. my $debarch = `dpkg --print-installation-architecture`; chomp $debarch; +my $subarch = ""; +if ( $debarch eq "alpha" ) { + $subarch = `awk '/^cpu model/ { print \$4; exit }' /proc/cpuinfo`; + chomp $subarch; + # possible values: EV3 EV4 Simulate LCA4 EV5 EV45 EV56 EV6 PCA56 PCA57 + # EV67 EV68CB EV68AL EV68CX EV7 EV79 EV69 + # canonify to relevant subarchs + if ( $subarch =~ /^(EV3|Simulate|LCA4|EV45)$/ ) { $subarch = "EV4"; } + if ( $subarch =~ /^(PCA57)$/ ) { $subarch = "PCA56"; } + if ( $subarch =~ /^(EV68.*|EV7.*)$/ ) { $subarch = "EV67"; } + # possible values now: EV4 EV5 EV56 PCA56 EV6 EV67 +} +# Debian version. +my $debver = `cat /etc/debian_version`; +chomp $debver; +# Accept only numeric versions and "testing/unstable" +if ( ! $debver =~ /^(\d+(\.\d+)*|testing\/unstable)$/ ) { $debver = "" } + # Set if dpkg package version is older than 1.10, thus missing dpkg-query. my $olddpkg = 0; if ( ! -x "/usr/bin/dpkg-query" ) { @@ -133,7 +151,7 @@ # add a header/footer. print "POPULARITY-CONTEST-0 TIME:",time," ID:$HOSTID ". - "ARCH:$debarch POPCONVER:$popconver\n"; + "ARCH:$debarch SUBARCH:$subarch DEBVER:$debver POPCONVER:$popconver\n"; for (sort { $popcon{$b}[0] <=> $popcon{$a}[0] } keys %popcon) {
[Falk Hueffner] Thank you for the patch. But I do not want to teach the popularity-contest client about all the subarchis in debian. I would prefer to leave this to some other package, being maintained by someone else. I believe there is something like this in d-i, and I would like a patch to use it. As for submitting the content of /etc/debian_version, we tried that for a while, but discovered that it was useless, because of the strange strings people place in them.
Petter Reinholdtsen <pere@hungry.com> writes: AFAIK, there is nothing in d-i that detects Alpha subarchitectures, for example, because they are not relevant there. Also, the level of detailedness is probably different for d-i. I don't want to gather random data, but answer conrete questions like "does anybody use sid on a pre-EV56 machine so that we shouldn't drop support for it". So we wouldn't teach popularity-contest about all kinds of subarchitectures, but only those where anybody cares about distinguishing them. Well, a majority probably doesn't ever fiddle with /etc/debian_version, so this seems hard to believe. Do you have the result somewhere?
Hi, I'd like to lobby again for the inclusion of my patch at http://bugs.debian.org/238687 again, which reports Alpha subarchitectures and the Debian version. The motivation is to decide whether to drop ev4 or ev56 support. The objections were: * Subarchitecture information should come from another package. Well, there is no such package right now, and it seems silly to start one containing 10 lines of code. Moreover, I would prefer, as a matter of principle, to only report information we are sure is needed for some concrete decision. * /etc/debian_version is unreliable. However, I don't think the percentage of users actively setting their /etc/debian_version to something bogus is that high, so it would be still useful. It would be nice to get some more opinions on this...
At least you can see what kernels are in use: From http://popcon.debian.org/main/base/by_vote 181 linux-image-2.6.15-1-486 295 0 0 0 295 182 linux-image-2.6.15-1-686 791 0 0 0 791 183 linux-image-2.6.15-1-686-smp 209 0 0 0 209 184 linux-image-2.6.15-1-alpha-generic 3 0 0 0 3 185 linux-image-2.6.15-1-alpha-smp 1 0 0 0 1 186 linux-image-2.6.15-1-k7 416 0 0 0 416 187 linux-image-2.6.15-1-k7-smp 27 0 0 0 27 188 linux-image-2.6.15-1-mac 1 0 0 0 1 189 linux-image-2.6.15-1-mckinley 3 0 0 0 3 190 linux-image-2.6.15-1-mckinley-smp 2 0 0 0 2 191 linux-image-2.6.15-1-mvme16x 1 0 0 0 1 192 linux-image-2.6.15-1-nslu2 2 0 0 0 2 193 linux-image-2.6.15-1-parisc 4 0 0 0 4 194 linux-image-2.6.15-1-parisc64 3 0 0 0 3 195 linux-image-2.6.15-1-powerpc64 2 0 0 0 2 196 linux-image-2.6.15-1-s390x 1 0 0 0 1 197 linux-image-2.6.15-1-s3c2410 1 0 0 0 1 198 linux-image-2.6.15-1-sparc64 16 0 0 0 16 199 linux-image-2.6.15-1-sparc64-smp 3 0 0 0 3 More importantly at this point there are still no reliable way to find out the sub-architecture. Collecting data is one thing, processing them is another. I would not mind too much reporting the sub-architecture if there was a Debian official way to get it. Actually you can easily know the numbers of submissions from each distributions using the version information: woody (unknown): 449 sarge (1.28): 2986 testing/unstable (1.31/1.32): 6333 outdated snapshot of testing/unstable (others): 641 I think it is better than what the debian_version would give you. Cheers,
Bill Allombert <allomber@math.u-bordeaux.fr> writes: That does not help in answering the above question for Alpha, since there are no subarchitecture specific kernels. I don't understand your point. I've posted a patch. Does it seem unreliable? Maybe. But anyway, such a way does not exist (and "subarchitecture" is way to fuzzy for this to work reliably and in a useful way anyway, IMHO.) So, meanwhile, what about my patch? Hmm, maybe it is, at least if we release a new version of popularity-contest after each stable release. So I wouldn't insist on that part of the patch.
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,
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