It might be useful to also send data about the package versions (this might
allow statistics about, for instance, how many people are using glibc 2.2-3
versus 2.2-4). Of course, the package versions should be reported only if they
are from the Debian archives (and not a local package version, which might have
sensitive info in the version part).

To find out if the package came from a Debian archive, take a look at
sources.list, ask the user which lines are mirrors of the official Debian
archive, and snoop at apt's cache of Packages files to get the version numbers.

I'm not sure this is a good idea.  First of all, it might accidentally leak
personal information that people don't want given out.  Secondly,
popularity-contest is only reliable because it's based on a _lot_ of people
voting; if we start dividing votes up between every version of kde (for
example) then we're depending on individual submissions, which are easily
corrupted or faked.  Plus using individual information is a bit of a privacy
invasion anyway (even with names removed).

The most interesting information for me would be how many people are:

	- running the "original" stable without changes

	- running the latest stable with updates

	- running the very latest unstable

	- running (like me) stable with a few packages upgraded from
	  unstable.

	- etc.

If we could find a way for popularity-contest to generalize something like
that and send it along, I think that would be okay.  Sending more specific
information makes me nervous.

Maybe we should just send the contents of /etc/debian_version.

Have fun,

Avery

----- Forwarded message from cesarb -----
possible).

How about this:

Do the following: create a page which lists "milestones" for the releases, and
make popularity-contest download it (put it in some debian.org host, so people
don't get nervous about leaking the fact that they use popularity-contest).

Put in it information for key packages, like this (feel free to change the
format, this suggestion is too hard to parse):

	potato
	potato+r1
	potato+r2
	potato+r3
	woody
	sid
base-files
	<=	2.2.0		potato+r3
	=	2.2.8		woody
	>	2.2.8		sid
libc6
	=	2.1.3-17	potato
	=	2.1.3-18	potato+r3
	=	2.2.3-1		woody
	>	2.2.3-1		sid

The first part gives the "order" of the releases, and the sections give the
"hints" to guess the Debian version. So, having base-files <= 2.2.0 means the
version is potato+r3, potato+r2, potato+r1, or potato (the <= applies also to
the order, not only to the version)

You'd have to code a script to extract the needed info daily from the Packages
files, and use only the "basic" packages (base, required, important, standard).

(I know this is too complex. I have this bad habit. Feel free to simplify.)
----- End forwarded message -----

package popularity-contest
retitle 97045 Please track package versions
stop

It would be very useful to maintainers to know what versions of packages
are in use and with what relative frequency.

It would be very useful to maintainers to know what versions of packages
are in use and with what relative frequency.

Hello Thomas,
I have no plan for popcon to report package versions. This would reduce privacy
and reduce the anonimity of the system too much.

On the other hand, popcon now provide separate statistics for stable, so you
can estimate the packages version frequency.

Also I think you are overstating the usefulness of packages version, unless people
use package outside of stable/testing/unstable, which then would increase the
privacy/security issue.

Cheers,

Hello Thomas,
I have no plan for popcon to report package versions. This would reduce privacy
and reduce the anonimity of the system too much.

On the other hand, popcon now provide separate statistics for stable, so you
can estimate the packages version frequency.

Also I think you are overstating the usefulness of packages version, unless people
use package outside of stable/testing/unstable, which then would increase the
privacy/security issue.

Cheers,

Hello,
It would be really interesting to start reporting also the version of
the package, for example it could answer questions like: how many have
installed the last upload in sid vs the version in testing? I think
the default visualization should remain as is, but with the
possibility to drill down on versions.

I dont honestly see how reporting a version cloud leak any personal
information or violate one's privacy, as long as we report versions
released on debian archives.

Thanks for considering,

The time granularity of popcon is larger than the current delay between
sid and testing, so I doubt it would work.

If you still use an outdated version of a package with a security hole, you
might not want to broadcast the fact, even if the package was part of the
Debian archives in the past, and even if you do not know yet about the hole.

Cheers,

Hello Bill,
could be in the archive for weeks/months but they will still have the
older version.

but there is no correlation between who submitted the report and the
value in it, so just knowing that there someone with the popcon active
on their machine with a security hole (which is different than
*exploitable*) is no much more knowledge than "there are system still
running linux 2.0 on the internet, let's go exploit them".

Cheers,