Software tab producing crazy results.

[tariqbuilds]

Software tab producing crazy results.

[cyphar]

The thing with package managers is that they vary greatly between distributions. Trying to come up with some unified way of scraping package information from them would be a nightmare.

Here are a few ideas I came up with:

• Maybe some configuration file the user provides to specify which binaries should be looked at?
• Look through all binaries in $PATH or, failing that, look in /bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin

The only problems I can think of is not discovering hidden packages (such as in /opt) and the fact that the first solution would be extremely tedious for end users.

[commonquail]

The only problems I can think of is not discovering hidden packages (such as in /opt) and the fact that the first solution would be extremely tedious for end users.

I concur, but I think the correct solution would be to find out how to solve that. It's entirely plausible that people will want to see different applications listed; why would I want to list something if I know I'll never use it?
@afaqurk is planning a means of persistence for a future iteration, to allow rearranging windows (cookies?). Down the line I imagine this could be leveraged in a similar fashion for this issue.

[kryten87]

Here's an alternative solution: the linux-dash application includes a configuration file listing the applications to check. It starts out with the most common applications, and over time more users will suggest additions to the list.

Something will always be missing from the list, but eventually it will get to the point where it covers 90%+ of the most important applications.

This list could also include the shell command to check the version of each application, and the widget could iterate over the list and scrape that info.

[commonquail]

A configuration file is on the roadmap, it's just a matter of finding out what it should do.

[donatj]

I believe a pull request I submitted that was accepted a few days ago fixed this, maybe check it out?

[tariqbuilds]

@gbb - is this still the case for your server? If recent changes address this, lets close this issue.

If not, lets explore your package manager & server environment setup and come up with a specific solution.

[gbb]

Seems improved, thanks for your work on it guys. dash is shaping up nicely.

Still some bugs? e.g. apache 2 says 'not installed'.
but: httpd-2.4.6 is installed.

It still lacks version numbers which is the real killer issue for me. Knowing at a glance that apache is installed is considerably less useful than knowing if it's the version that needs an emergency security patch. Python 2.7 or python 3? Postgres 9.2 or 9.3 or 8.4?

My feeling is that a dashboard should report quickly on things that are important for acting upon. I don't ever need to take an action on the path of a program. I may need to act on whether its installed and which version it is.

I also think listing the path is a bad idea. What about systems with multiple copies (e.g. python 2, python 3, Java ...) in different locations? What happens if you pick up the default install and not the active install? (/opt/, as others mentioned). It's something I've almost never needed to care about as a sysadmin.

I appreciate that polling for version numbers is more difficult - wrote an app to do it for a few things a few months back as part of an installer for GIS stuff - but it's really valuable. Particularly since I can find the active path of an app with 'which' very easily, but checking the version takes more time - is it -v , --version, something else? Which part of the text string is it, if I'm trying to check automatically?

[cyphar]

Well, you could sort out the "installed" problem by observing the $PATH environment variable (although, you have the problem of different users having different PATHs, etc). Also, not all software understands program --version. I think most of these problems will have to be dealt with using configuration files (since we can't really cover every possible system setup by default), which come with sane defaults. The project would still be a drop-in dashboard, but would be customisable.

If we end up saying no to config files, we'll need to describe what this project's "general target system" looks like, so that sysadmins can see whether or not this project will work with their particular setup. It would also aid the design of the project, as everyone would have a unified idea of what system they are targeting with a feature.

tl;dr: the power of customisation or the simplicity of targeting only one type of system?

[commonquail]

@gbb: I doubt anyone disagrees with you but the issue simply cannot be solved with deciding, as mentioned above, whether we'll target a very specific setup or support configuration (and then how to do that). I'm for the latter as the former would be largely useless to me (it will either be too narrow or too general), but configuration is not a fully trivial problem.

That said, I think I can cook up a solution that will work but by no means is guaranteed to be future proof, which is to say that there's a good chance you'll have to reconfigure later on. This would let you specify the applications of interest, the version argument, and the path to search.

/cc @afaqurk

[Kami-no]

Installed on Gentoo, not all apps detected.

One of the solutions for Gentoo (found here http://how-to.wikia.com/wiki/How_to_find_all_packages_emerged(installed)_on_a_Gentoo_Linux_system)
ls -d /var/db/pkg// | cut -f5- -d/

Here is my example:
ls -d /var/db/pkg// | cut -f5- -d/ | grep php
app-admin/eselect-php-0.7.1-r3
dev-lang/php-5.5.9

But Dashboard says "not installed".

I suppose we also need configuration file to select software we care and it's versions.

[AnthonyPorthouse]

Something else I've noticed regarding finding software is on my setup using NGINX with php-fpm the PATH environment variable is not set. However we could potentially load in the default path from /etc/environment.