No dia 7 de Janeiro de 2011 03:53, Philip Brown <[email protected]> escreveu: > On Thu, Jan 6, 2011 at 5:12 PM, Maciej (Matchek) Blizinski > <[email protected]> wrote: >> No dia 2 de Janeiro de 2011 20:55, Philip Brown <[email protected]> escreveu: >>> >> You can say that it's enough to place a symlink from /opt/csw/lib to >> another place that contains the binary file and programs will work - >> fine, > > and that is indeed my position > >> do we do that in other packages? We don't, we place the >> actual files directly under /opt/csw/lib. > > and that's not really any kind of deliberate decision or policy, but > merely a convenient side effect of > --prefix=/opt/csw > for MOST packages.
Deploying a vital component of the csw ecosystem based on a side effect doesn't sound like a good idea. Just like you don't change things in packages just because checkpkg said so, you don't plan your layout just because the install script happened to put them there. Quite often the result of install script's work will be aligned with what we won't, but this is a convenience rather than a good way to create packages. Ultimately, files end up at the locations of our deliberate choice. If we haven't made a decision regarding shared libraries, let's take a look at this issue now. > however, for packages where prefix != /opt/csw, we dont always do that. > (in fact, I think we RARELY do that) > > > >> It's true that MySQL >> executables are under /opt/csw/mysql5, but it's an exception rather >> than a rule. > > Yes, this is exactly my point. programs with their own sub-prefix are > special. Perhaps we should make a specific variation on our standards, > for programs with sub-prefixes. > Something like, "if shared libs are generated under $PREFIX != > /opt/csw, it is recommended > to create a symlink in /opt/csw/lib, pointing to the appropriate library" Why are you thinking in terms of "shared libs are generated under"? Isn't it better to think of shared libraries as a shared resource, without obscuring the logic with prefixes? > I will also point out, that our berkeleydb packages also keep their > shared libs under their own subprefix, rather than keeping the actual > .so files in /opt/csw/lib My personal opinion is that this is a suboptimal layout. Just that we used to do something doesn't mean that it's the right thing to do. >> MySQL binaries under /opt/csw/mysql/bin do not have their own shared >> libraries; > > > ahh.. actually, many of them use libmysqlclient. > > Perhaps you did a check "ldd /opt/csw/mysql/bin/*", but forgot they > are using isaexec? > > but if on other hand you check like this... > > bender$ ldd /opt/csw/mysql5/bin/sparcv8/mysql|grep mysql > libmysqlclient.so.15 => > /opt/csw/mysql5/lib/sparcv8/mysql/libmysqlclient.so.15 > > > Perhaps you meant they do not use "private" shared libraries? Yes. What I meant is that they use libmysqlient, and that libmysqlclient is not a private, MySQL's own thing, but rather a public, common resource. It's indeed used by MySQL executables, but not only. There are other executables that also use them. The fact that some users of a common resource are special, doesn't mean that the resource should be. _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
