You are not logged in.
When I mentioned votes, I was talking about voting for package priority within a user's system. Not voting for the things we like most, but the things we require most.
A script to compile installed packages and allow the user to cast a vote on some or all of them. And that's the data that would be sent. As such the user would indicate, within their installed packages, which ones he considers crucial. Statistics could still be elaborated normally, and cast votes would weight on each package (on a separate statistic if you wanted).
Anyways, just to clarify that's what I was thinking about votes. Not voting for favorite packages, although one can say it would partially reflect that.
I probably made this post longer than it should only because I lack the time to make it shorter.
- Paraphrased from Blaise Pascal
Offline
When I mentioned votes, I was talking about voting for package priority within a user's system. Not voting for the things we like most, but the things we require most.
A script to compile installed packages and allow the user to cast a vote on some or all of them. And that's the data that would be sent. As such the user would indicate, within their installed packages, which ones he considers crucial. Statistics could still be elaborated normally, and cast votes would weight on each package (on a separate statistic if you wanted).
Anyways, just to clarify that's what I was thinking about votes. Not voting for favorite packages, although one can say it would partially reflect that.
The question remains: what would high votecount mean? That developers are _required_ to do sth? I don't see that happening. That the community thinks it's important? We already have votes in the bugtracker for bugs and feature requests. Just as a loaded gun beats four aces, a patch may mean more than hundreds of votes.
Apart from testing something, I don't install packages I don't need. Which is more important: vim, xorg-server or firefox?
Offline
One thing that's always slightly bugged me about pkgstats is that I have quite a lot of packages installed that I don't use much (I tend to be lazy and only remove things if I need the space), and I wonder how many others are the same, leading to "false" readings. But I think Allan answered that one: it's as much about what people don't install as what they do. What's the point in devs maintaining packages in [extra] if they're never used?
Stats submitted.
0 Ok, 0:1
Offline
I'm installing, testing and uninstalling, so there's less chance of me submitting apps I don't actually use, thus my heroic behavior helps the devs from spreading themselves too thin.
Offline
RetroX wrote:It would be nice if it tracked AUR/unknown repo packages as well, though.
It does.
I have no clue how I didn't notice that.
One thing that I do find quite odd:
pacman: 99.85 %
How would they even install packages in the first place?
Offline
How would they even install packages in the first place?
./configure && make && make install
Offline
RetroX wrote:How would they even install packages in the first place?
./configure && make && make install
That's not installing packages with a package manger; it's just building them and copying the files into the root filesystem. They probably use the same terminology, but that's not what I meant.
Offline
karol wrote:RetroX wrote:How would they even install packages in the first place?
./configure && make && make install
That's not installing packages with a package manger; it's just building them and copying the files into the root filesystem. They probably use the same terminology, but that's not what I meant.
That's installing pacman :-)
Offline
karol wrote:RetroX wrote:How would they even install packages in the first place?
./configure && make && make install
That's not installing packages with a package manger; it's just building them and copying the files into the root filesystem. They probably use the same terminology, but that's not what I meant.
They probably use pacman-git.
Offline
They probably use pacman-git.
That would be Toofishes (Dan).
Online
Or use an alternative package manager like clyde. There are probably more.
< Daenyth> and he works prolifically
4 8 15 16 23 42
Offline
Or use an alternative package manager like clyde. There are probably more.
Clyde depends on libalpm which in the pacman package.
Online
Dieter@be wrote:Or use an alternative package manager like clyde. There are probably more.
Clyde depends on libalpm which in the pacman package.
Hmm, you sure?
[root@dieter-ws-a7n8x-arch ~]# clyde -Rs pacman
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: aif: requires pacman
:: package-query: requires pacman
:: pacman-contrib: requires pacman
:: pkgstats: requires pacman
:: yaourt: requires pacman>=3.3.3
[root@dieter-ws-a7n8x-arch ~]# pacman -Qi clyde-git | grep Depends
Depends On : lua-lzlib lua-yajl-git luasocket luafilesystem
[root@dieter-ws-a7n8x-arch ~]#
< Daenyth> and he works prolifically
4 8 15 16 23 42
Offline
Yes... it is a libalpm wrapper. It is amusing that a package manager does not have correct deps!
Online
Yes... it is a libalpm wrapper. It is amusing that a package manager does not have correct deps!
Seems like you're right
[root@dieter-ws-a7n8x-arch ~]# clyde -Rs --nodeps pacman
warning: pacman is designated as a HoldPkg.
HoldPkg was found in target list. Do you want to continue? [y/N] y
Remove (3): pacman-3.4.1-1 pacman-mirrorlist-20100825-1 libfetch-2.33-1
Total Removed Size: 2.37 MB
Do you want to remove these packages? [Y/n]
(1/3) removing pacman [###########################################################################################################################################################################################################################] 100%
warning: /etc/pacman.conf saved as /etc/pacman.conf.pacsave
warning: /etc/makepkg.conf saved as /etc/makepkg.conf.pacsave
warning: /etc/pacman.d/mirrorlist saved as /etc/pacman.d/mirrorlist.pacsave
(2/3) removing pacman-mirrorlist [###########################################################################################################################################################################################################################] 100%
(3/3) removing libfetch [###########################################################################################################################################################################################################################] 100%
[root@dieter-ws-a7n8x-arch ~]# clyde -Syu
lua: error loading module 'lualpm' from file '/usr/lib/lua/5.1/lualpm.so':
libalpm.so.5: cannot open shared object file: No such file or directory
stack traceback:
[C]: ?
[C]: in function 'require'
/usr/share/lua/5.1/clydelib/util.lua:2: in main chunk
[C]: in function 'require'
/usr/bin/clyde:5: in main chunk
[C]: ?
< Daenyth> and he works prolifically
4 8 15 16 23 42
Offline
Pierre, if you want make standalone script, please see [1]. It was my try to get a counter without things of archlinux.de, maybe it can help.
It is currently running on http://danimoth.archlinuxppc.org/arconte, and haven't all the feature that pkgstats has, but maybe it is a good start point.
Offline
It'll most likely get more complex. ;-) But I could implement it in a way to make it easy to reuse for other arch-related projects.
Offline
Neat stuff!
But the stuff should be read with a barrel of salt.
Installation base doesn't really tell you much about popularity.
Take the 90+% of gstreamer.
Gstreamer is on top of the list and hence the most popular multimedia player, right? Wrong. libwebkit depends on it, and hence about half of the webbrowsers. I'd like to argue that the web browsers are the main reason for why people have gstreamer installed.
Yes, this is an example from the fun part of the statistics, but it holds true for lots of other stuff as well. Why is avahi installed on 90+% of the machines? Because the package maintainer configured cups and sane to link against avahi.
Simply put, the reason why a lot of stuff is 'popular' is not because the stuff is popular but because something depends on it, be it a necessary dependency or not. It's something to be kept in mind, imho.
The approach of moving stuff with almost no install base to repos lower in the maintenance chain and vice versa sounds sane to me though, for this task the statistics make sense.
Offline
Gstreamer is on top of the list and hence the most popular multimedia player, right? Wrong. libwebkit depends on it, and hence about half of the webbrowsers. I'd like to argue that the web browsers are the main reason for why people have gstreamer installed.
It's not a mediaplayer, it is a multimedia framework - and besides browsers, is pulled in by gnome.
But in general, I trust the people who check this data to be aware of the dependencies.
Offline
Gstreamer is on top of the list and hence the most popular multimedia player, right? Wrong. libwebkit depends on it, and hence about half of the webbrowsers. I'd like to argue that the web browsers are the main reason for why people have gstreamer installed.
It's not a mediaplayer, it is a multimedia framework - and besides browsers, is pulled in by gnome.
I know they call it a framework but I don't see a big difference between gstreamer and the other media players, each can be used as backend, each one has frontends, they are all mainly used for reproducing multimedia, they are media players.
But in general, I trust the people who check this data to be aware of the dependencies.
I sure hope so, that install base doesn't necessarily mean popularity but can also mean dependency is definitely something to be kept in mind. With the AUR the situation is slightly different, but largely depends on how people use the AUR. I guess AUR helpers, probably not deliberately, encourage the usage of AUR PKGBUILDs without modification, which would result in the same dependency problem.
I think there are nice tools that help with viewing relations between packages and I hope they'll be used. Until dynamic linking finds wider usage and most dependencies can be made optdepends we'll have to deal with issues arising from buildtime dependencies.
Offline
Installation base doesn't really tell you much about popularity.
You just work in reverse if the package in question is more of a dependency than a program that can be "used". GStreamer is definitely not something you would use/run directly, unlike MPlayer. In MPlayer's case, it is both a dependency and a popular program. However, a popular dependency which does not necessarily have a practical use-case is _still_ popular, because in the end you have to take care of it if the parent popular package needs it. As such, purpose is served.
Last edited by schivmeister (2010-09-30 09:29:45)
I need real, proper pen and paper for this.
Offline
Well, I think installing pkgstats is the least one can do for helping developers if they 'waste' lots of hours and efforts on maintaining those packages for us common users. So it's installed on one more PC.
Offline
Simply put, the reason why a lot of stuff is 'popular' is not because the stuff is popular but because something depends on it, be it a necessary dependency or not. It's something to be kept in mind, imho.
If this is the case, whether or not that a package was installed explicitly or as a dependency should be tracked as well.
Offline
Heh, this helped me weed out some unnecessary packages from core that i had installed, just check what the rest of the folks have uninstalled.
How the hell can one of the participants not have pkgstats installed? And another doesn't have pacman...
Offline
And another doesn't have pacman...
Offline