No dia 1 de Outubro de 2010 16:37, Philip Brown <[email protected]> escreveu: > I will preface my email, with the general premise: "Life is not simple". > It would be lovely if there were a nice clean way to deal with this... > but lets face facts, rather than to deny them. There Is No simple > clean automated, "always applies" solution to this. > That being said, lets move on to discuss what Can be done, in the face > of life's messy realities :)
Yes, I'm well aware that it's not possible to come up with a simple rule that humans would agree to adhere to. > On 9/29/10, Maciej (Matchek) Blizinski <[email protected]> wrote: >> .... >> file=opt/csw/lib/libavcodec-0.4.9-pre1.so pkgname=CSWffmpeg >> expected=['CSWlibavcodec-0-4-9-pre1'] >> file=opt/csw/lib/libavformat-0.4.9-pre1.so pkgname=CSWffmpeg >> expected=['CSWlibavformat-0-4-9-pre1'] >> file=opt/csw/lib/libpostproc.so.0.0.1 pkgname=CSWffmpeg >> expected=['CSWlibpostproc0', 'CSWlibpostproc-0'] >> >> With these three, I don't know myself - does it make sense to separate >> these 3 libraries? Two of them seem to have the version in sync, but >> the version is entangled with the library name, instead of being >> located after the ".so" bit, where nature intended. >> > > This is exactly the sort of thing I envisioned running into. Thank you > for doing the hard research to dig up a specific example. > This example is extra complicated, since there is NO SONAME to any of them. > interestingly, though, there is a cross-dependancy in the libs themselves. > libavformat needs libavcodec. > Interestingly, however, it needs, by name, "libavcodec.so". no rev. > > So in this case, it would serve no purpose whatsoever to split the > libraries out from the main ffmpeg package, or to split them up > independantly. A newer version of the package will transparently > update older versions, it would seem. Yes, libavcodec.so is a symlink: /opt/csw/lib/libavcodec.so -> libavcodec-0.4.9-pre1.so I'm not sure what would developers do if they needed to update the API, but I'm guessing that they would release a new package that would no longer provide libavcodec.so, but libavcodec.so.1 or similar. What matters is the correspondence between the SONAME and the library file name, and revisions are just a convenient notation for humans. I don't quite agree with the splitting serving no purpose. You can always have a client program needing libavcodec.so, and not needing other libraries. Consider this scenario: /opt/csw/lib/libavformat.so needs libavcodec.so /opt/csw/bin/foo needs libavcodec.so At some point, libavformat.so goes away, nothing else links to it. You want to remove it. However, it's packaged together with libavcodec.so, and /opt/csw/bin/foo still depends on it. If you had those two libraries packaged separately, you could retire libavformat.so. > I think you might do well to go with my original theory, slightly expanded: > > Unless you find a shared object, of filename "lib*.so*", AND it has a > "SONAME", AND that name has a double-numeric rev (eg: > libfoo.so.#.#), then you should just leave it alone. I understand and I agree with the first two criteria: It makes sense to separate the library out, if it is named lib*.so*, and has a SONAME. I don't get the bit with the double-numeric versions. What matters is the presence of SONAME, and the contents is a conventional notation, why would any numbers matter? I'd add a third criterion, which is: It must be in one of the default search locations, in our case: /opt/csw/lib with optional isalist subdirectories. _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
