RE: [Cooker] Re: [CHRPM] libjpeg-6b-23mdk 9.0 lib policy
On Wed, 2002-05-29 at 00:55, Borsenkow Andrej wrote: So this means that they'll have to always have the -static-devel and -devel installed to be able to build stuff? Unless something very smart is done ... the decision to use static or dynamic part happens at runtime when you _use_ these development libraries. You must have both available. Or you build them as dynamic or static only. Huh?! The decision on which libs a binary uses is entirely determined at compile time... The only time you need the static libs installed is at compile time (and only if you are statically linking). No precompiled binary that is linked to static libs requires the static libs to be present to run. Or did I totally miss what you were saying. -- TTFN, Lonnie Borntreger
RE: [Cooker] Re: [CHRPM] libjpeg-6b-23mdk 9.0 lib policy
On Wed, 2002-05-29 at 00:55, Borsenkow Andrej wrote: So this means that they'll have to always have the -static-devel and -devel installed to be able to build stuff? Unless something very smart is done ... the decision to use static or dynamic part happens at runtime when you _use_ these development libraries. You must have both available. Or you build them as dynamic or static only. Huh?! The decision on which libs a binary uses is entirely determined at compile time... The only time you need the static libs installed is at compile time (and only if you are statically linking). No precompiled binary that is linked to static libs requires the static libs to be present to run. Or did I totally miss what you were saying. I meant compile time, sorry. Run time == when you compile another application using these libraries -andrej
RE: [Cooker] Re: [CHRPM] libjpeg-6b-23mdk 9.0 lib policy
Perhaps I don't see the benefits of this policy, maybe somebody can enlighten me? Well, the intention is to allow more than one version of library to be installed while allowing you to explicitly select build (development) version to use. Having both versioned and unversioned libraries in one package would mean you can't have more than one version installed. -andrej
Re: [Cooker] Re: [CHRPM] libjpeg-6b-23mdk 9.0 lib policy
Perhaps I don't see the benefits of this policy, maybe somebody can enlighten me? Well, the intention is to allow more than one version of library to be installed while allowing you to explicitly select build (development) version to use. Having both versioned and unversioned libraries in one package would mean you can't have more than one version installed. I understand the benefits of the lib policy very well, let me rephrase my question: What does lib policy version 9 provide over the previous one? What will splitting the -devel into -static-devel -devel packages bring? Stefan
Re: [Cooker] Re: [CHRPM] libjpeg-6b-23mdk 9.0 lib policy
Stefan van der Eijk [EMAIL PROTECTED] writes: I understand the benefits of the lib policy very well, let me rephrase my question: What does lib policy version 9 provide over the previous one? What will splitting the -devel into -static-devel -devel packages bring? - save space on your fs by not installing things you will never use. - save space on distrib by having rpm taht could go on the third cd. it is always a big figth to fit every important rpm on the first 2 cds. - moth of these .a are never used and will never be, so we no more ship them. same reasons. - .. -- Yves Duret [EMAIL PROTECTED] piouk toujours et meme apres !
Re: [Cooker] Re: [CHRPM] libjpeg-6b-23mdk 9.0 lib policy
I understand the benefits of the lib policy very well, let me rephrase my question: What does lib policy version 9 provide over the previous one? What will splitting the -devel into -static-devel -devel packages bring? - save space on your fs by not installing things you will never use. - save space on distrib by having rpm taht could go on the third cd. it is always a big figth to fit every important rpm on the first 2 cds. - moth of these .a are never used and will never be, so we no more ship them. same reasons. - .. And what happens in practice? All these rpm's are just installed on the cluster: libmng1-static-devel-1.0.3-2mdk ash-static-0.3.8-1mdk XFree86-static-libs-4.2.0-11mdk libelf0-static-devel-0.8.0-3mdk libnetpbm9-static-devel-9.24-2mdk libjpeg62-static-devel-6b-23mdk libtiff3-static-devel-3.5.7-4mdk libaa1-static-devel-1.4.0-0.rc5.3mdk recode-static-devel-3.6-3mdk libpng3-static-devel-1.2.1-8mdk t1lib1-static-devel-1.3.1-5mdk libldap2-devel-static-2.0.21-4mdk libusb0.1_4-static-devel-0.1.5-2mdk libungif4-static-devel-4.1.0-18mdk Nobody is going todo any effort in updating the BuildRequires of the packages (all the -static-devel packages are installed on the cluster anyway, why bother?). About the space argument: I'm wondering if this is _really_ going to save that much space. Take a look at how big those packages are: $ du -s *static* 128 a2ps-static-devel-4.13-13mdk.i586.rpm 240 ash-static-0.3.8-1mdk.i586.rpm 44 console-tools-static-devel-0.2.3-31mdk.i586.rpm 16900 glibc_lsb-devel-static-2.2.90-4mdk.i586.rpm 64 libaa1-static-devel-1.4.0-0.rc5.3mdk.i586.rpm 56 libelf0-static-devel-0.8.0-3mdk.i586.rpm 412 libforms0-static-devel-0.-4mdk.i586.rpm 88 libjpeg62-static-devel-6b-23mdk.i586.rpm 224 libldap2-devel-static-2.0.21-4mdk.i586.rpm 28 liblm_sensors1-static-devel-2.6.2-4mdk.i586.rpm 116 libmng1-static-devel-1.0.3-2mdk.i586.rpm 84 libnetpbm9-static-devel-9.24-2mdk.i586.rpm 88 libpng3-static-devel-1.2.1-8mdk.i586.rpm 96 libtiff3-static-devel-3.5.7-4mdk.i586.rpm 24 libungif4-static-devel-4.1.0-18mdk.i586.rpm 16 libusb0.1_4-static-devel-0.1.5-2mdk.i586.rpm 60 libwraster2-static-devel-0.80.0-5mdk.i586.rpm 720 recode-static-devel-3.6-3mdk.i586.rpm 160 t1lib1-static-devel-1.3.1-5mdk.i586.rpm 268 WindowMaker-static-devel-0.80.0-5mdk.i586.rpm 2392XFree86-static-libs-4.2.0-11mdk.i586.rpm Most of these packages are 100Kb. You're probably going to have more overhead in the rpm package (and perhaps filesystem overhead) then you're ever going to win back. My opinion is that you're only going to make things more complex like this, thus creating more overhead in keeping the BuildRequires of packages correct (but MDK doesn't really care about this, no?). Why not first take a look at all the duplicate files in the packages and filter those out? There's probably more to save there, and that won't provide you more unexpected hidden work... Stefan
RE: [Cooker] Re: [CHRPM] libjpeg-6b-23mdk 9.0 lib policy
I understand the benefits of the lib policy very well, let me rephrase my question: What does lib policy version 9 provide over the previous one? What will splitting the -devel into -static-devel -devel packages bring? - save space on your fs by not installing things you will never use. - save space on distrib by having rpm taht could go on the third cd. it is always a big figth to fit every important rpm on the first 2 cds. - moth of these .a are never used and will never be, so we no more ship them. same reasons. - .. And what happens in practice? All these rpm's are just installed on the cluster: libmng1-static-devel-1.0.3-2mdk ash-static-0.3.8-1mdk I was wrong (I missed static part). I do not understand this - for any package using libtool you can NOT split it into dynamic and static part. It is simply impossible because you have single *.la interface to both. They belong all together. -andrej
Re: [Cooker] Re: [CHRPM] libjpeg-6b-23mdk 9.0 lib policy
I was wrong (I missed static part). I do not understand this - for any package using libtool you can NOT split it into dynamic and static part. It is simply impossible because you have single *.la interface to both. They belong all together. So this means that they'll have to always have the -static-devel and -devel installed to be able to build stuff? Stefan
RE: [Cooker] Re: [CHRPM] libjpeg-6b-23mdk 9.0 lib policy
I was wrong (I missed static part). I do not understand this - for any package using libtool you can NOT split it into dynamic and static part. It is simply impossible because you have single *.la interface to both. They belong all together. So this means that they'll have to always have the -static-devel and -devel installed to be able to build stuff? Unless something very smart is done ... the decision to use static or dynamic part happens at runtime when you _use_ these development libraries. You must have both available. Or you build them as dynamic or static only. -andrej
