search

rocksclusters / FingerPrint

Fingerprinting application dependencies
http://fingerprint.readthedocs.org/en/latest/
Other
7 stars 7 forks source link

Incorporate information on the origin of binary packages #4

Open yarikoptic opened 11 years ago

yarikoptic commented 11 years ago

NB initially thought just to suggest in my repy on https://github.com/lclementi/FingerPrint/issues/1 but decided that it might be worth a separate "thread"

Have you approached incorporation of information on the origins of the packages?

i.e. there could be multiple binary package repositories providing them for the system to be fingerprinted on. And per se package version alone might not be sufficient to identify the origin of a package. So -- wouldn't it make sense to include such information into the .swirl (i.e. packageX of version Y cames from repository Z on date D, and here is the information on that repository: URL, name, ...).

If you see a good fit for that within FingerPrint -- I could possibly contribute the Debian-related pieces

lclementi commented 11 years ago

On Sun, Mar 10, 2013 at 12:49 PM, Yaroslav Halchenko < notifications@github.com> wrote:

NB initially thought just to suggest in my repy on lclementi/FingerPrint#1https://github.com/lclementi/FingerPrint/issues/1but decided that it might be worth a separate "thread"

Have you approached incorporation of information on the origins of the packages?

i.e. there could be multiple binary package repositories providing them for the system to be fingerprinted on. And per se package version alone might not be sufficient to identify the origin of a package. So -- wouldn't it make sense to include such information into the .swirl (i.e. packageX of version Y cames from repository Z on date D, and here is the information on that repository: URL, name, ...).

If you see a good fit for that within FingerPrint -- I could possibly contribute the Debian-related pieces

Just a couple of issues with that:

  1. fingerprint was mainly targeted for high performance system, where it is common practice to recompile all libraries and binaries with different compilers and different optimization options (mpich2, openmpi, etc.). Maybe in this type of environment having the package repository sources might not be really helpful
  2. We always thought to figerprint as a user space, distribution independent, system tool. What we really care is to track the soname of the dependencies so that eventually we can rebuild a system which provides those symbols.

What we hope is that we can create a fingerprint on debian and use that fingerprint to get a list of symbols i need to built my rocks appliance (redhat based).

The reason why we get the package name, version, and file hash at the moment is only to detect system changes and tell the user exactly what the administrator has changed.

Given that I think it is a really interesting feature and I will consider it for future inclusion. Although now I have dynamic tracing on my table with an extensive set of tests on XSEDE.

Luca