On Sep 5, 2006, at 6:05 PM, Jean-François Mertens wrote: > Sorry Justin _ just thought this deserves wider discussion ... > So a number of cc's ... > > JF > > On 06 Sep 2006, at 00:37, TheSin wrote: > >> oh I forgot about libxine, > And dont forget whatever gst-plugins-good-0.10 (or something like > that...) >> I thought I got everything that deped on 5. Thanks yet again, I'm >> gonna try and get to this stuff in a few hours, I just got back >> into the office, been in meetings all day. Like I have been >> preching for awhile, we almost need one shlib per shlibs pkg, cause >> they don't always update all at the same time. > > So happy to hear this ! Finally basic logic retuns ... > The 'shlibs-policy' seems conceptually a complete confusion between > properties of a pkg > and properties of individual libs within them .. > And with pkgs (eg, seamonkey, evolution in my exp dir), with dozens > of shlibs, it is hopeless > _ just a nightmare : the set itself of shlibs changes with every > change in either %c or %v or ... > Given that we have in addition a "Shlibs" field, which DOES give to > fink all relevant info > about individual libs within a pkg, we shouldn't have to distinguish > between individual libs > within a '-shlibs' splitoff (I mean , split the splittoff into > whatever subsets _ > such subdivision varies with very change in %c and %v ; hence is un- > maintainable) > > > the confusion within fink seems to be really here : > > _ the pkg-specific things in should be "item1" (ie, the "SpilOffs"- > shlibs field ...) > _ the lib-specific things should be "item2" _ ie, the ShLibs field _ > and fink has all liberty to re-interpret such things in dpkg dep > instructions etc) > > I.e., _ the current type of setup for info files is exactly right, > but there is a lot of work to be done > by fink to use the information correctly.
We are limited here by what dpkg can do. Everything that dpkg installs has to be in a package, and the SplitOff mechanism was designed to allow more than more package to be produced from a single .info file. Now the problem is this: once a shared library has had other things link to it, we must be careful not to remove it if those other things are still present. We may upgrade, but only if the upgrade is backwards-compatible. So we have a policy which says: if your package declares a shared library by means of the shlibs field, then other packages can rely on the following: if they depend on this package (as specified in the shlibs field), then the shared library they need will always be available. (Strictly speaking, this policy only applies to shared libraries with a public API: if a package creates a shared library which will only be used by the package, and doesn't export an API which would allow it to be linked by other packages, then the policy need not apply.) It is obviously easiest, when packaging, to put all the shared libraries into a single shlibs splitoff, but of course this can cause problems if the shared libraries are updated independently. However, with some care, an upgrade can be constructed which accounts for all of the needed packages. It's easiest to illustrate this with an example. Suppose that package foo-1.0-1 has a splitoff foo-shlibs-1.0-1 which contains two shared libraries: libfoo.1.dylib and libbar.1.dylib. But now suppose that foo is updated to version 2.0, which provides libfoo.2.dylib and libbar.1.dylib. That is, libbar was not updated, but libfoo was. In the new package, we will have two splitoffs: foo2-shlibs and bar1- shlibs. (Well, we have more than that, because we'll have foo2-dev and bar1-dev in addition, at least.) Dividing the old splitoffs in half is not really a big problem. Everything here will be built from the new foo-2.0 tarball. But we also need to construct foo-shlibs-1.0-2 for backward compatibility, and that one will still be based on the foo-1.0 tarball. The trick here is to *only* store libfoo.1.dylib in foo- shlibs-1.0-2, but to *also* make it depend on the new bar1-shlibs splitoff of the other package. What does this accomplish? Well, the previous Shlibs field promised that if we depend on foo-shlibs we will get both libfoo.1.dylib and libbar.1.dylib, and this promise has been kept: the first library is actually *in* the package, and the second library is in a (new) dependency of the package. Of course, in the foo-shlibs-1.0-2 package, the Shlibs field only indicates libfoo.1.dylib, while the new bar1-shlibs package will have a Shlibs field for libbar.1.dylib. I hope this example was clear. -- Dave ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
