On 28/09/10, 01:23:50, Maciej "(Matchek)" Blizinski <[email protected]> wrote regarding Re: [csw-maintainers] An idea for a shared libraries policy:
> > once you step into that realm things become more messy. > > remember that upstream numbering is sometimes out of sync with the lib > > numbering. > > > > your proposal may "simplify" the number of versions of a library per > > package . however, it will *add* complexity to the naming and package > > building process in other ways. > > > > I'm not neccessarily against it. I'm just pointing out it isn't > > neccessarily the "simple" choice > It's true. Specifically problematic are bits of software that already > embed a number in the package name, or the soname. For example > apache2rt package contains libapr-1.so.0. The corresponding pkgname > would be something along the lines of CSWlibapr10 or CSWlibapr-10, or > other punctuation variants. These names aren't strikingly pretty, but > I think it's possible to make them consistent. These packages are only used as dependencies so the naming doesn't have to be appealing. No user should need to directly install a run time. They should even be in the list offered to users, only the top level names should be, like jpeg, python. > Another thing is, that we don't need to put every shared library in a > separate packages. Only when the SONAME changes and it's incompatible, like major version changes on software, eg, apache2. > This policy would only apply to libraries that > other packages link to. If a shared library is linked to only by > binaries from the same package, there's no benefit from separating out > the libraries. Yes there is, it may change later. That's why we are where we are, because in the first place there isn't a need. James. _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
