Re: Versioned Symbols
Hello, On Tue, Mar 11, 2003 at 02:02:30PM +0900, Junichi Uekawa wrote: You could also take an approach of pulling out libssl-dev, and making packages to Build-Depend on libssl0.9.7-dev libssl0.9.6-dev explicitly, and starting to rebuild packages against them. That way, within Debian, it is not possible to build a package that is simultaneously linked against libssl0.9.6 and libssl0.9.7. That is what libpkg-guide documents. Sorry, I did not follow the discussion closely, so I may understand this wrong. But how does your proposal solve the following situation? libfoo1 Build-Depends on libssl0.9.6-dev libfoo2 Build-Depends on libssl0.9.7-dev libbreakseverything Build-Depends on libfoo1-dev and libfoo2-dev brokenprogram Build-Depends on libbreakseverything-dev Building of which package should fail here? Jochen -- Omm (0)-(0) http://www.mathematik.uni-kl.de/~wwwstoch/voss/index.html pgpf4FXCSq7un.pgp Description: PGP signature
Re: Versioned Symbols
On Mon, Mar 10, 2003 at 09:22:53AM -0500, Stephen Frost wrote: ... This doesn't solve the problem, and -Bsymbolic only solves a portion of the problem. ... I have looked at -Bsymbolic, and it seems to be doing about the same as my proposed change (see elsewhere), however the docs on this potato box are too ambiguous to be usable, so here are some (stupid) questions (don't bother to answer those) and some food for thought depending on what the answers to the stupid questions are. 1. Is -Bsymbolic applied to the .so or the binary calling it? (I assume the .so but it does not matter here). 2. If an .so is built with -Bsymbolic, can it still be used by programs linked against a non-Bsymbolic copy of the same .so? 3. If a binary is linked against a -Bsymbolic .so, can it still be used with a non-Bsymbolic lib with the same .so name? And finally the real question (I'll figure the above out myself, but don't want to delay this message while I investigate): 4. If the answers to both of the above are yes, what harm would there be in simply turning -Bsymbolic on by default in the debian copy of binutils (and contributing it upstream)? Whatever the solution my point here and elsewhere is that when there is a choice, making a lot of maintainers and developers work hard (whether on code, scripts or upstream negotiations) is almost always worse than fixing some part of the toolchain to do the work for them by default (freedom dictates that the default can be turned off). Friendly Jakob -- This message is hastily written, please ignore any unpleasant wordings, do not consider it a binding commitment, even if its phrasing may indicate so. Its contents may be deliberately or accidentally untrue. Trademarks and other things belong to their owners, if any.
Re: Versioned Symbols
On Mon, Mar 10, 2003 at 10:47:40AM -0300, Henrique de Moraes Holschuh wrote: Agreed. As far as programs build on Debian systems won't run elsewhere, it is just a matter of pushing the versioning of said core libraries to the LSB, which shouldn't be too difficult if we do it right and send in patches. Uh, no, the LSB doesn't standardise every library that is shipped by every distribution other than Debian. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!''
Re: Versioned Symbols
On Tue, 11 Mar 2003, Anthony Towns wrote: On Mon, Mar 10, 2003 at 10:47:40AM -0300, Henrique de Moraes Holschuh wrote: Agreed. As far as programs build on Debian systems won't run elsewhere, it is just a matter of pushing the versioning of said core libraries to the LSB, which shouldn't be too difficult if we do it right and send in patches. Uh, no, the LSB doesn't standardise every library that is shipped by every distribution other than Debian. It doesn't need to, either. Whatever isn't in the LSB doesn't matter as far as interoperatibility is concerned [if the LSB is done right]. And it is NOT like the programs fail to run. You get annoying warnings (that could even be removed from ld.so, for that matter). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Versioned Symbols
On Wed, 12 Mar 2003, Anthony Towns wrote: On Tue, Mar 11, 2003 at 10:47:34AM -0300, Henrique de Moraes Holschuh wrote: It doesn't need to, either. Whatever isn't in the LSB doesn't matter as far as interoperatibility is concerned [if the LSB is done right]. Uh, libqt isn't standardised by the LSB, and probably won't be. Yuck. Big hole in the LSB, then (IMHO). Anyway, patch ld.so, then. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Versioned Symbols
* Richard Braakman ([EMAIL PROTECTED]) wrote: I think it would avoid the problem, but it would be a major headache to deal with in practice. It would be as bad as tcl4.* used to be, and I'm glad we left THAT behind. It won't solve the problem, please read my reply to him for a better understanding of what will happen, and my d-d-a post from last month for a better understanding of the overall problem. Stephen pgp3B4uCr0Xf1.pgp Description: PGP signature
Re: Versioned Symbols
* Junichi Uekawa ([EMAIL PROTECTED]) wrote: What about it would avoid libssl0.9.6 problems? Nothing I saw would solve the problems of multiple versions of a library ending up linked into the same process except the symbol versioning portion, which is what I'm advocating here but you seem to be against while offering 'solutions' that either don't deal with the problem at all or only solve a portion of it. Following libpkg-guide will avoid future similar problems. Wrong, wrong, wrong. Quit spreading misinformation. To work around libssl problem, you can certainly use symbol versioning. That's a solution and what I'm trying to push for. You could also take an approach of pulling out libssl-dev, and making packages to Build-Depend on libssl0.9.7-dev libssl0.9.6-dev explicitly, and starting to rebuild packages against them. That way, within Debian, it is not possible to build a package that is simultaneously linked against libssl0.9.6 and libssl0.9.7. That is what libpkg-guide documents. Will you please just quit with the foolish claims? Even if packages build-depend on a specific library version a running process can end up being linked against two versions of a library. Here we go, again: At time X libssl0.9.6-dev is in Debian. At time X ssh is built against libssl0.9.6-dev. At time Y libssl0.9.7-dev is uploaded to Debian. At time Y libldap2 is built against libssl0.9.7-dev. At time Z a user installs libssl0.9.6, libssl0.9.7, ssh, libldap2 and libpam-ldap, all of which are in Debian and all of which can be installed without any problems with dependencies. At time Z the ssh process will end up linked (AT RUNTIME) to both libssl0.9.6 *AND* libssl0.9.7. ssh will end up segfaulting because of this. *Please* tell me you see and understand the problem. I'm really getting tired of having to explain it to you over and over again. Stephen pgpCgcOxQsY52.pgp Description: PGP signature
Re: Versioned Symbols
At time X libssl0.9.6-dev is in Debian. At time X ssh is built against libssl0.9.6-dev. At time Y libssl0.9.7-dev is uploaded to Debian. At time Y libldap2 is built against libssl0.9.7-dev. At time Z a user installs libssl0.9.6, libssl0.9.7, ssh, libldap2 and libpam-ldap, all of which are in Debian and all of which can be installed without any problems with dependencies. At time Z the ssh process will end up linked (AT RUNTIME) to both libssl0.9.6 *AND* libssl0.9.7. ssh will end up segfaulting because of this. Thanks for your clarification. That is caused by dlopen used by PAM, which I assume is caused by dlopening with RTDL_GLOBAL, where there is an option to dlopen with RTDL_LOCAL. regards, junichi
Bug#184368: sematic error, 2.3.1 The package name
Package: debian-policy Section 2.3.1 says: Package names must consist of lower case letters (a-z), digits (0-9), plus (+) and minus (-) signs, and periods (.). It should say something like: Package names must not consist of anything other than lower case letters (a-z), digits (0-9), plus (+) and minus (-) signs, and periods (.). because it is not desirable, and not the current convention to make packages contain all of the items in the list. eg why force apt to have digits, plus and minus signs and periods. It would have to have a name like apt00+-.. to be valid. Drew Daniels
CVS joy: fixed the date at the top; updated the location
CVSROOT:/cvs/debian-policy Module name:debian-policy Changes by: joy Tue Mar 11 16:32:56 MST 2003 Modified files: . : virtual-package-names-list.txt Log message: fixed the date at the top; updated the location
CVS joy: sync
CVSROOT:/cvs/debian-policy Module name:debian-policy Changes by: joy Tue Mar 11 16:59:03 MST 2003 Modified files: debian : changelog Log message: sync
CVS joy: fixed typos noticed by Osamu Aoki, indented by a space, various formatting fixes to eliminate redundancy, fixed content sections
CVSROOT:/cvs/debian-policy Module name:debian-policy Changes by: joy Tue Mar 11 16:57:43 MST 2003 Modified files: . : virtual-package-names-list.txt Log message: fixed typos noticed by Osamu Aoki, indented by a space, various formatting fixes to eliminate redundancy, fixed content sections
Re: Versioned Symbols
On Wed, 12 Mar 2003, Junichi Uekawa wrote: That is caused by dlopen used by PAM, which I assume is caused by Or dlopen used by glibc (nss modules), or dlopen used by anything else. Apache modules can kill apache that way too, for example (afaik anyway). dlopening with RTDL_GLOBAL, where there is an option to dlopen with RTDL_LOCAL. hmm... how does that behaves when the conflict is two or more libs down the chain from the PoV of the stuff being dlopened? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Bug#184368: sematic error, 2.3.1 The package name
On Tue, Mar 11, 2003 at 03:57:07PM -0600, Drew Scott Daniels wrote: Package: debian-policy Section 2.3.1 says: Package names must consist of lower case letters (a-z), digits (0-9), plus (+) and minus (-) signs, and periods (.). It should say something like: Package names must not consist of anything other than lower case letters (a-z), digits (0-9), plus (+) and minus (-) signs, and periods (.). because it is not desirable, and not the current convention to make packages contain all of the items in the list. eg why force apt to have digits, plus and minus signs and periods. It would have to have a name like apt00+-.. to be valid. Please do not push pedantic argument too much :-) Double negative expressions are error prone and difficult to understand for non-native speakers. I think it is fine as is since the original text uses consist of instead of contain. BTW, I have never seen any package name starting any of +, -, or ., nor I have seen any package name with repeated .. I guess common sense rules. -- Osamu Aoki [EMAIL PROTECTED] Cupertino CA USA, GPG-key: A8061F32
