On 9/29/10, Maciej (Matchek) Blizinski <[email protected]> wrote: > > Do we have instances in which we package multiple version of the same > dynamically loaded object into one package? I think not, but if we > had, they could be separated as well.
not to my memory. The "include older binary versions" issue, usually (possibly ONLY) comes up for traditional shared libraries only. >> What about if there are multiple objects in the package? > > The idea is to not have multiple objects in one package. It's best of > the granularity corresponds to the chunks in which we'll phase out > shared libraries. If there are multiple libraries that are to be > phased out together, they could live in one package. However, this > might be hard to predict, so it's safer to have each object in a > separate package. There are some things that conceptually should always be grouped together. For example: atspi /opt/csw/lib/libcspi.so.0.10.11 /opt/csw/lib/libloginhelper.so.0.0.0 /opt/csw/lib/libspi.so.0.10.11 augeas /opt/csw/lib/libaugeas.so.0.10.1 /opt/csw/lib/libfa.so.1.3.0 boost_rt (a BUNCH) fltk /opt/csw/lib/libfltk.so.1.1 /opt/csw/lib/libfltk_forms.so.1.1 /opt/csw/lib/libfltk_gl.so.1.1 /opt/csw/lib/libfltk_images.so.1.1 It would arguably be a mistake, to get into a packaging scheme which might allow some of these to accidentally get out of sync with one another. Ideally, in my opinion, they should remain as part of a single unified runtime package. > CSWlibfoo-devel: > /opt/csw/include/foo.h > /opt/csw/lib/libfoo.so → libfoo.so.1 I agree, libxxx.so symlinks belong in devel packages. If you split out a runtime, you dont need the libxxx.so symlink. (but that's what we do right now already, I think. We just ship the "real" file, with no symlinks, in our "rt" packages) Random comment: I think that libraries with SONAMEs that include minor revs, are more likely to fall prey to the need for splitting out. In contrast, libraries that have ONLY a major rev: "libxxx.so.1" - tend to play nicely and respect compatibility between revs very well. (and by implication, will probably not need fancy sub-packages). So you might go easy on the checkpkg checks, in those cases. _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
