Re: [RFC] xulrunner, shlibs, and dependencies.
snip Yes, sonames can be more or less arbitrary strings. You can certainly use sonames with debian in them with a fairly high degree of confidence that upstream won't collide with them. THAT is cool. FWIW, FYI, I did some work on that and managed to build xulrunner with basic sonames through quite clean additions to the mozilla build system for the base tree and the nspr tree. I still need to do similar work for the security tree (being the libnss and friends), though (their build system is really brain damaged, and i'm not even talking about the fact they include libjpeg, libcairo, libbz2, (...) sources). The good thing is that shlibs work correctly now :) I also managed to build epiphany on top of it, but that required a few adjustments I'll submit in the BTS when the package will be uploaded, which I believe might occur in 10 days or so. Cheers, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] xulrunner, shlibs, and dependencies.
Le mardi 06 décembre 2005 à 20:43 +0100, Mike Hommey a écrit : THAT is cool. FWIW, FYI, I did some work on that and managed to build xulrunner with basic sonames through quite clean additions to the mozilla build system for the base tree and the nspr tree. I still need to do similar work for the security tree (being the libnss and friends), though (their build system is really brain damaged, and i'm not even talking about the fact they include libjpeg, libcairo, libbz2, (...) sources). BTW, did you get it to build against the Debian versions of these libraries? That would be even cooler ;) -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: [RFC] xulrunner, shlibs, and dependencies.
On Tue, Dec 06, 2005 at 09:04:57PM +0100, Josselin Mouette [EMAIL PROTECTED] wrote: Le mardi 06 décembre 2005 à 20:43 +0100, Mike Hommey a écrit : THAT is cool. FWIW, FYI, I did some work on that and managed to build xulrunner with basic sonames through quite clean additions to the mozilla build system for the base tree and the nspr tree. I still need to do similar work for the security tree (being the libnss and friends), though (their build system is really brain damaged, and i'm not even talking about the fact they include libjpeg, libcairo, libbz2, (...) sources). BTW, did you get it to build against the Debian versions of these libraries? That would be even cooler ;) That's done ; they actually provide a way to use the system libraries, except for libbz2, for which i sent them a patch for. I'm actually trying to get the most patches possible applied upstream... Cheers, Mike -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] xulrunner, shlibs, and dependencies.
On Sat, Dec 03, 2005 at 12:28:36AM -0800, Steve Langasek [EMAIL PROTECTED] was heard to say: On Sat, Dec 03, 2005 at 08:58:45AM +0100, Mike Hommey wrote: Will all the tools resolving the dependencies be fine with a dependency on a virtual package without one an a real package ? (like for zlib1g-dev | libz-dev) Yes. See apt's Provides for an example of this. Just in case there's any confusion: the problem with depending only on a virtual package is that some tools tend to pick an arbitrary Provider of the package, which can in turn lead to unpredictable behavior. If only one provider at a time is installable, this shouldn't be a problem, though. Daniel signature.asc Description: Digital signature
Re: [RFC] xulrunner, shlibs, and dependencies.
On Sat, Dec 03, 2005 at 08:58:45AM +0100, Mike Hommey wrote: So my idea is the following : - First, I want to provide the libs with a correct soname. It won't be compatible with upstream until some people use clue sticks, but i'll do my best for them to improve on that point. Having a correct soname will enable us to actually use the shlibs mecanism. - Now, the problem is that we can't really use the sonames correctly, because if we succeed in the clue stick batting, we'll have different sonames, which, in the long term, would be painful. So, I'd like to provide a dummy gecko-x.y-serial or such package, which would correctly depend on the libxul package (with strict version if necessary), and the .shlibs in the libxul-dev package would say to depend on the gecko-x.y-serial package. If you don't want to make up sonames (and I think having debian-specific sonames is fine, personally), I think that having libxul provide a virtual package to use in dependencies is the best option (whether that's gecko-x.y-serial, or libxul1debianX, makes no real difference). Will all the tools resolving the dependencies be fine with a dependency on a virtual package without one an a real package ? (like for zlib1g-dev | libz-dev) Yes. See apt's Provides for an example of this. There are two advantages to managing sonames even when upstream does not: it lets you interface better with un-packaged software (but *only* if that software is built against the Debian version!), and it allows co-installability of different library versions. You need to decide whether these features are important enough for your application to warrant spinning your own sonames. (My guess is no.) My concern is more about what it becomes when we hopefully get upstream to use sonames. Someone suggested me to use specific sonames like libxul.so.d1. Does that really work ? Do shlibs work as well with that ? If this is the case, I think i have my solution... Yes, sonames can be more or less arbitrary strings. You can certainly use sonames with debian in them with a fairly high degree of confidence that upstream won't collide with them. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: [RFC] xulrunner, shlibs, and dependencies.
On Sat, Dec 03, 2005 at 12:28:36AM -0800, Steve Langasek [EMAIL PROTECTED] wrote: On Sat, Dec 03, 2005 at 08:58:45AM +0100, Mike Hommey wrote: So my idea is the following : - First, I want to provide the libs with a correct soname. It won't be compatible with upstream until some people use clue sticks, but i'll do my best for them to improve on that point. Having a correct soname will enable us to actually use the shlibs mecanism. - Now, the problem is that we can't really use the sonames correctly, because if we succeed in the clue stick batting, we'll have different sonames, which, in the long term, would be painful. So, I'd like to provide a dummy gecko-x.y-serial or such package, which would correctly depend on the libxul package (with strict version if necessary), and the .shlibs in the libxul-dev package would say to depend on the gecko-x.y-serial package. If you don't want to make up sonames (and I think having debian-specific sonames is fine, personally), I think that having libxul provide a virtual package to use in dependencies is the best option (whether that's gecko-x.y-serial, or libxul1debianX, makes no real difference). Will all the tools resolving the dependencies be fine with a dependency on a virtual package without one an a real package ? (like for zlib1g-dev | libz-dev) Yes. See apt's Provides for an example of this. So why do we keep providing transition packages, then ? There are two advantages to managing sonames even when upstream does not: it lets you interface better with un-packaged software (but *only* if that software is built against the Debian version!), and it allows co-installability of different library versions. You need to decide whether these features are important enough for your application to warrant spinning your own sonames. (My guess is no.) My concern is more about what it becomes when we hopefully get upstream to use sonames. Someone suggested me to use specific sonames like libxul.so.d1. Does that really work ? Do shlibs work as well with that ? If this is the case, I think i have my solution... Yes, sonames can be more or less arbitrary strings. You can certainly use sonames with debian in them with a fairly high degree of confidence that upstream won't collide with them. THAT is cool. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] xulrunner, shlibs, and dependencies.
On Sat, Dec 03, 2005 at 10:16:38AM +0100, Mike Hommey wrote: On Sat, Dec 03, 2005 at 12:28:36AM -0800, Steve Langasek [EMAIL PROTECTED] wrote: On Sat, Dec 03, 2005 at 08:58:45AM +0100, Mike Hommey wrote: So my idea is the following : - First, I want to provide the libs with a correct soname. It won't be compatible with upstream until some people use clue sticks, but i'll do my best for them to improve on that point. Having a correct soname will enable us to actually use the shlibs mecanism. - Now, the problem is that we can't really use the sonames correctly, because if we succeed in the clue stick batting, we'll have different sonames, which, in the long term, would be painful. So, I'd like to provide a dummy gecko-x.y-serial or such package, which would correctly depend on the libxul package (with strict version if necessary), and the .shlibs in the libxul-dev package would say to depend on the gecko-x.y-serial package. If you don't want to make up sonames (and I think having debian-specific sonames is fine, personally), I think that having libxul provide a virtual package to use in dependencies is the best option (whether that's gecko-x.y-serial, or libxul1debianX, makes no real difference). Will all the tools resolving the dependencies be fine with a dependency on a virtual package without one an a real package ? (like for zlib1g-dev | libz-dev) Yes. See apt's Provides for an example of this. So why do we keep providing transition packages, then ? What transition packages do you mean? If you mean, why don't we use Provides: instead of transition packages?, the answer is that apt will never automatically replace a real package with a virtual one on upgrades. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: [RFC] xulrunner, shlibs, and dependencies.
Mike Hommey wrote: Hi As you may or may not know, I'm currently working on packaging xulrunner, which is ought to be the central point for all future mozilla technology, meaning that at more or less long term, all mozilla products (firefox, thunderbird, etc.) will be built on top of it. That will be indeed a great improvment in both memory (who really wants to have libraries loaded twice just because you run 2 of their programs) and security management. Anyways, the mid-term plan would be to migrate the applications that use mozilla as a platform (such as epiphany, galeon, kazehakase, etc.) to build on top of xulrunner (libxul, actually) instead of the current mozilla, and instead of having a firefox-dev package as requested in #322521. I'd like to make everybody's life easier, and would like to improve the current situation, but I'd like some feedback on my ideas, to know if my solutions are the proper ones or if I should explore some other ways. Nowadays, when the mozilla ABI breaks, which happens quite often (though it is supposed to get better in the future), all the epiphany, galeon and friends break and need rebuilding with the newer mozilla (if there's no API breakage at the same time, in which case some changes are needed in the programs). In the current situation, the dependencies are quite useless. We can't really stick to a strict dependency, which would be painful (every new upload of mozilla would need a rebuild of its reverse dependencies), and we can't set a = dependency either, because of the breakage. So my idea is the following : - First, I want to provide the libs with a correct soname. It won't be compatible with upstream until some people use clue sticks, but i'll do my best for them to improve on that point. Having a correct soname will enable us to actually use the shlibs mecanism. - Now, the problem is that we can't really use the sonames correctly, because if we succeed in the clue stick batting, we'll have different sonames, which, in the long term, would be painful. So, I'd like to provide a dummy gecko-x.y-serial or such package, which would correctly depend on the libxul package (with strict version if necessary), and the .shlibs in the libxul-dev package would say to depend on the gecko-x.y-serial package. Assuming this is otherwise fine, wouldn't it be better to do what apt does. Namely have gecko-x.y-serial be a virtual package provided by libxul. Travis signature.asc Description: OpenPGP digital signature
Re: [RFC] xulrunner, shlibs, and dependencies.
On Fri, Dec 02, 2005 at 05:52:03PM -0800, Steve Langasek [EMAIL PROTECTED] wrote: On Fri, Dec 02, 2005 at 08:47:47PM +0100, Mike Hommey wrote: As you may or may not know, I'm currently working on packaging xulrunner, which is ought to be the central point for all future mozilla technology, meaning that at more or less long term, all mozilla products (firefox, thunderbird, etc.) will be built on top of it. That will be indeed a great improvment in both memory (who really wants to have libraries loaded twice just because you run 2 of their programs) and security management. I think this question is more suited for debian-devel than for debian-release, fwiw. Library packaging is not the exclusive responsibility of the release team. :) Moving there. So my idea is the following : - First, I want to provide the libs with a correct soname. It won't be compatible with upstream until some people use clue sticks, but i'll do my best for them to improve on that point. Having a correct soname will enable us to actually use the shlibs mecanism. - Now, the problem is that we can't really use the sonames correctly, because if we succeed in the clue stick batting, we'll have different sonames, which, in the long term, would be painful. So, I'd like to provide a dummy gecko-x.y-serial or such package, which would correctly depend on the libxul package (with strict version if necessary), and the .shlibs in the libxul-dev package would say to depend on the gecko-x.y-serial package. If you don't want to make up sonames (and I think having debian-specific sonames is fine, personally), I think that having libxul provide a virtual package to use in dependencies is the best option (whether that's gecko-x.y-serial, or libxul1debianX, makes no real difference). Will all the tools resolving the dependencies be fine with a dependency on a virtual package without one an a real package ? (like for zlib1g-dev | libz-dev) There are two advantages to managing sonames even when upstream does not: it lets you interface better with un-packaged software (but *only* if that software is built against the Debian version!), and it allows co-installability of different library versions. You need to decide whether these features are important enough for your application to warrant spinning your own sonames. (My guess is no.) My concern is more about what it becomes when we hopefully get upstream to use sonames. Someone suggested me to use specific sonames like libxul.so.d1. Does that really work ? Do shlibs work as well with that ? If this is the case, I think i have my solution... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
