On Mon, Feb 14, 2011 at 10:10 PM, Ben Walton <[email protected]> wrote: > Well, let's decide this issue then. Before going to a vote, is anyone > against the proposal[1] as currently written? If there are no > dissenters, we can simply make it policy and carry on with this > matter. >
The only section I felt was somewhat harry was the portion that spoke about linking to an older library. This portion pre-supposes a solution to this problem when it hasn't really been discussed (at least in the context of this policy). I think the subject of how to enable access to older libraries for end-user developers merits its own discussion and/or policy. The method described in the document has some serious downfalls and I would prefer a method more like the one used by ubuntu. This places the include.h and the libfoo.so link into a versioned package like libfoo2.0-dev. This allows the end-user to choose the default development version of the library to use with builds by choosing the approriate -dev package. The libfoo-rt package then would only have the libfoo.so.1 file needed by executables. Example: appfoo1 /opt/csw/bin/appfoo (depends on /opt/csw/libfoo.so.1) libfoo1rt /opt/csw/lib/libfoo.so.1 libfoo1-dev /opt/csw/include/foo.h /opt/csw/lib/libfoo.so -> libfoo.so.1 appfoo2 /opt/csw/bin/appfoo (depends on /opt/csw/libfoo.so.2) libfoo2rt /opt/csw/lib/libfoo.so.2 libfoo2-dev /opt/csw/include/foo.h /opt/csw/lib/libfoo.so -> libfoo.so.2 Now libfoo1rt and libfoo2rt can coexist and the end-user can choose which library they want to develop against by choosing the appropriate -dev package. _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
