I know hod dumb my question might sound...

I have a chinook boot from one 16gb card, and a diablo from a second one. The current version of the program xournal works perfectly on my chinook version, yet what is installed with "apt-get install xournal" is a different version that doesn't work (program loads, but none of its features work).

my question(s) are:
1) is it possible to simply download the chinook installation package (using the chinook boot), and then copy it to the other boot
(i.e. can I use "apt-get -d install xournal" once it is installed? | where will it be downloaded to?)

2) is it possible to find the exact version of what I have installed so that I can install that particular build on my diablo boot (using apt-get once again)?

Thank you

2) From the command line you can use 'apt-cache policy name-of-package', it will show you the version you have installed (and the version that's available in the repo too).

ta-t3,
this has always bothered me, I come from Windows and products have About pages with version numbers and build dates embedded within the app itself.
I can technically run multiple concurrent applications each a different version and get different information from each - useful for testing purposes.

I found a cludgy way of embedding the build datestamp inside liqbase (a gcc define constructed with a smidgen of perl as part of the makefile)

To open up the question slightly (since you have answered him correctly straight away), for future reference is there an alternative/standard way to embed versioning information inside an application, I certainly did not feel comfortable having to shell out and ask apt for the version of a binary I am already running.

why not? I only use shell (unless the gui is mandatory), and I was asking for the correct command here...

This is because the version number reported by apt-cache (or any apt- or dpkg function which reports versions) isn't, strictly speaking, the same as the application's version number. It's really the version number embedded in the debian package (edit: in the 'control' file, which is not part of the application) - it may or may not be related to the application's version (its About page - and many applications have them).

Consider: The Debian packager takes the sources of CoolApp from upstream, which is the version that upstream calls "1.3". Now, most Debian packagers would include 1.3 in the Debian package number, but in addition to that there's always at least one more digit: The packager's internal version. The first release will typically be -1, so the Debian package version will be 1.3-1. But nothing stops the packager from calling it 0.0-3-1A, it's just that it's usually not done (but it could be, if this was e.g. a port to a new and unsupported platform).

Later the packager finds a problem in the package (could have forgotten to set the correct Section:, for example, which gives folks trouble installing it, or, worse, forgotten to include some important files). So the next package gets the version 1.3-2. Now 1.3-1 and 1.3-2 are critically different (particularly if 1.3-1 was missing important files), but they both show '1.3' in the About page.

Then there may be re-packaging for Diablo v.s. Chinook, and the version number may be manipulated in interesting ways to mark the difference.

Along comes ItT hacker LetsImproveThings and grabs the original 1.3-2 maemo/debian-packaged sources, applies some extra hacks to extend the functionality, and calls it 1.3-99LiTrel4. This version is even more different, but is still 1.3 in the About page..

To sum it up, every application should really have an About entry/menu/page or something to show its upstream version number. But the package version number is independent. It's a good idea to let it reflect the upstream version number though (sometimes there isn't a different upstream maintainer, but the same applies anyway).

Thanks TA, that clarifies the reasoning perfectly