Re: Question on patches
On Sat, Jul 19, 2003, Matthias Kurz wrote: Would patches that implement (as options, turned off by default) shared libraries and relocation be acceptable? I'm in a situation that I need those features, but dread having to fork a set of package spec files etc. for my own use. I think, the shared library problem needs to be addressed some day, anyway. What are there for known problems ? I think uncontrolled dependencies (automatically picked up shared libs) are the greatest problem, aren't they ? Some of the reasons are mentioned in the FAQ AFAIK. Instead of patching all the many spec-Files that have disable-shared set etc., wouldn't it be possible to introduce a global setting (with a default of no). Yes, I plan for a with_shared option which all packages can support. The question which is still unanswered is _HOW_ the packages should support this. At least without executable wrappers this option at least disallows multiple OpenPKG instances on the same machine. But that certainly has to be the price for using shared libraries. The only workaround on ELF platforms is that we either patch all packages to correctly supply an -rpath to hard-code the paths to the shared libraries or write a little utility which post-adjusts installed libxxx.so files and hard-codes their path. The whole shared library issue is on the TODO list for OpenPKG 2.0. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Re: Question on patches
On Sat, Jul 19, 2003 at 11:54:10AM +0200, Ralf S. Engelschall wrote: On Sat, Jul 19, 2003, Matthias Kurz wrote: Would patches that implement (as options, turned off by default) shared libraries and relocation be acceptable? I'm in a situation that I need those features, but dread having to fork a set of package spec files etc. for my own use. I think, the shared library problem needs to be addressed some day, anyway. What are there for known problems ? I think uncontrolled dependencies (automatically picked up shared libs) are the greatest problem, aren't they ? Some of the reasons are mentioned in the FAQ AFAIK. Autsch. Instead of patching all the many spec-Files that have disable-shared set etc., wouldn't it be possible to introduce a global setting (with a default of no). Yes, I plan for a with_shared option which all packages can support. I hope not in a way that one has to specify -Dwith_shared=yes for each and every package. The question which is still unanswered is _HOW_ the packages should support this. At least without executable wrappers this option at least disallows multiple OpenPKG instances on the same machine. That was a little bit surprising as every platform i have to cope with knows something like rpath. Actually they all use ELF... And from my experience there are only few problems with this, these days. Alas more than zero. But that certainly has to be the price for using shared libraries. The only workaround on ELF platforms is that we either patch all packages to correctly supply an -rpath to hard-code the paths to the shared libraries or write a little utility which post-adjusts installed libxxx.so files and hard-codes their path. The whole shared library issue is on the TODO list for OpenPKG 2.0. -- Matthias Kurz; Fuldastr. 3; D-28199 Bremen; VOICE +49 421 53 600 47 Im prämotorischen Cortex kann jeder ein Held sein. (bdw) __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Re: Question on patches
On Sat, Jul 19, 2003, Matthias Kurz wrote: [...] Instead of patching all the many spec-Files that have disable-shared set etc., wouldn't it be possible to introduce a global setting (with a default of no). Yes, I plan for a with_shared option which all packages can support. I hope not in a way that one has to specify -Dwith_shared=yes for each and every package. You don't have to, just add %with_shared yes to your ~/.rpmmacros file and you'll be done. And with openpkg-tool's build command you also have to specificy it just once: for building of all packages and then it's sticky. I think it has to be an %option and not something else special, because currently all those things are %options in OpenPKG... The question which is still unanswered is _HOW_ the packages should support this. At least without executable wrappers this option at least disallows multiple OpenPKG instances on the same machine. That was a little bit surprising as every platform i have to cope with knows something like rpath. Actually they all use ELF... And from my experience there are only few problems with this, these days. Alas more than zero. Yes, exactly: the with_shared=yes certainly cannot be a portable solution in general, but for all important platforms which OpenPKG officially supports, it can be provided in a portable enough way. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Re: Question on patches
On Sat, Jul 19, 2003 at 02:35:02PM +0200, Ralf S. Engelschall wrote: On Sat, Jul 19, 2003, Matthias Kurz wrote: [...] Instead of patching all the many spec-Files that have disable-shared set etc., wouldn't it be possible to introduce a global setting (with a default of no). Yes, I plan for a with_shared option which all packages can support. I hope not in a way that one has to specify -Dwith_shared=yes for each and every package. You don't have to, just add %with_shared yes to your ~/.rpmmacros file and you'll be done. And with openpkg-tool's build command you also have to specificy it just once: for building of all packages and then it's sticky. I think it has to be an %option and not something else special, because currently all those things are %options in OpenPKG... It seems to me that it's probably best to continue to limit shared libraries to those packages that really need them to work with non-openpkg programs (e.g. unixodbc, myodbc) or that must be built with shared libraries to enable other openpkg packages (perl and the postgresql perl support). If all packages that could have shared libraries built were modified to allow this, I would probably specify the default to be off, and turn it on for individual packages in my ~/.openpkg/build file. Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC UUCP: camco!bill PO Box 820; 6641 E. Mercer Way FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 URL: http://www.celestial.com/ My brother sent me a postcard the other day with this big satellite photo of the entire earth on it. On the back it said: ``Wish you were here''. -- Steven Wright __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Re: Question on patches
On Sat, 2003-07-19 at 02:54, Ralf S. Engelschall wrote: On Sat, Jul 19, 2003, Matthias Kurz wrote: Would patches that implement (as options, turned off by default) shared libraries and relocation be acceptable? I'm in a situation that I need those features, but dread having to fork a set of package spec files etc. for my own use. I think, the shared library problem needs to be addressed some day, anyway. What are there for known problems ? I think uncontrolled dependencies (automatically picked up shared libs) are the greatest problem, aren't they ? Some of the reasons are mentioned in the FAQ AFAIK. Instead of patching all the many spec-Files that have disable-shared set etc., wouldn't it be possible to introduce a global setting (with a default of no). Yes, I plan for a with_shared option which all packages can support. The question which is still unanswered is _HOW_ the packages should support this. At least without executable wrappers this option at least disallows multiple OpenPKG instances on the same machine. But that certainly has to be the price for using shared libraries. The only workaround on ELF platforms is that we either patch all packages to correctly supply an -rpath to hard-code the paths to the shared libraries or write a little utility which post-adjusts installed libxxx.so files and hard-codes their path. The whole shared library issue is on the TODO list for OpenPKG 2.0. The rpath solution sounds like a neat idea since it needs to be done only once, instead of with an rc script. Being able to do post-adjustment also helps for my case where I'm building relocatable packages. Cheers Conrad -- __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
Question on patches
Hi Would patches that implement (as options, turned off by default) shared libraries and relocation be acceptable? I'm in a situation that I need those features, but dread having to fork a set of package spec files etc. for my own use. Cheers Conrad -- Conrad Steenberg [EMAIL PROTECTED] __ The OpenPKG Projectwww.openpkg.org Developer Communication List [EMAIL PROTECTED]
