On Thu, Oct 11, 2012 at 08:46:49AM +0200, Jacob Carlborg wrote: > On 2012-10-11 04:54, Jesse Phillips wrote: [...] > >"Mister programmer man, you have unspecified library versions for... > >What do would you like to do with them? Did the currently selected > >version work out for you?" The PM tells the programmer. > > So this is just a guessing game, trail and error? > > I think it would be much better to work with packages and not > individual libraries. You would just tell the build tool, compiler or > whatever to use package "foo". Then the package manager figures out > what libraries and dependencies it needs to link to and also the path > to the import files. [...]
Yeah, one of the poor design decisions of the early Redhat packaging system was to allow packages to depend on individual files, rather than packages. The result was a disastrous mess: some packages export different versions of the same file, and only a subset of them will work, leading to hair-tearing dependencies. Packages would step over each other's files, causing problems with each other and the rest of the system that depended on the same files, ad nauseum. More modern packaging systems deal with packages as units, and do not allow packages to export the same files. Plus, packages can come with metadata that specify the exact version, build, etc., of a library, making it possible for multiple versions of the same library to exist on a system, and programs to pick up the exact version they were compiled with. A huge improvement indeed. You'll be surprised at how many applications will fail horribly because a careless library author changed the ABI (often without changing the API) without bumping the library version, causing calls to the old library functions to fail inexplicably, or worse, produce subtly wrong results. T -- There are 10 kinds of people in the world: those who can count in binary, and those who can't.