Benjamin Reed <[EMAIL PROTECTED]> wrote:
> One question it does bring up, that I remember being mentioned before,
> is that of library dependencies. Right now I have them set up with
> dependencies like so, which was what I saw in examples when we were
> first doing separate shlibs packages:
>
> rrdtool:
> Depends: %N-shlibs (>= %v-%r)
> Replaces: %N (<< %v-%r)
> Suggests: %N-bin
>
> rrdtool-shlibs:
> Replaces: rrdtool (<< %v-%r)
>
> rrdtool-bin:
> Depends: %N (>= %v-%r)
>
I recommend instead:
rrdtool:
Depends: %N-shlibs (= %v-%r)
rrdtool-shlibs:
Replaces: rrdtool (<< 1.0-3)
Suggests: %N-bin
rrdtool-bin:
Depends: %N-shlibs
Replaces: rrdtool (<< 1.0-3)
Here's the reasoning.
1) "Replaces" is being used because there formerly was a package named
rrdtool which contained some files that are now stored in -bin or
-shlibs. So when updating, fink needs to know that it is OK to
overwrite those files. The version mentioned should be the first
version where the splitting was done. It won't change when the package
is updated. (You could also include this line in rrdtool, but it is
redundant there.)
2) Nothing should depend on %N. This is crucial for the correct
operation of the system.
3) rrdtool (which contains headers and static library) should exactly
match the version of rrdtool-shlibs it was created with.
4) Note that a user using dselect (in the far future) will never install
rrdtool, only rrdtool-shlibs and rrdtool-bin. So the "Suggests"
field belongs in rrdtool.
> dpkg will install multiple versions of rrdtool-shlibs, right?
>
Not exactly. When rrdtool gets a new major version, you will create
packages rrdtool2, rrdtool2-shlibs, rrdtool2-bin. The things which will
coexist then are rrdtool-shlibs and rrdtool2-shlibs.
Any backward-compatible API change should be accomodated by replacing
rrdtool-shlibs by a new version. An incompatible change requires a new
major version number, and requires both shared libraries to be available at
runtime.
(One interesting point about the way this works: rrdtool contains a
symbolic link roughly like librrdtool.dylib -> librrdtool.1.dylib .
rrdtool2, which will conflict with rrdtool, contains a symbolic link
librrdtool.dylib -> librrdtool.2.dylib . So at compile time, the
currently installed headers (in rrdtool or rrdtool2) will match the correct
version of the library. This is also why it's important that the
install_names of these libraries be librrdtool.1.dylib and
librrdtool.2.dylib .
> But right now, we have no way of really planning ahead for a
> version that's too high, like, if rrdtool version 2 is out.
>
> If someone makes a package that links against librrd.1, what
> do they put as depends?
>
> If they make it "rrdtool-shlibs (>= %v-%r)" then rrdtool-shlibs
> 2.0.0-1 would match, and it would happily upgrade and break
> things on an update-all.
See above. They put as depends either rrdtool-shlibs or rrdtool2-shlibs.
Once version 2 is out and you've created the rrdtool2* packages, you
would encourage other package maintainers to upgrade when they can.
Eventually, nobody uses version 1 anymore.
> In the RPM world, RPMs automatically "provide" any librrd.*
> files, and then interrogate all of the binaries of a package and
> determine what libraries they need and add them as Depends.
> I'm pretty sure debian's package stuff do the same thing, but
> I don't have as much experience with them.
>
This is coming. See the Roadmap in the shared-libraries CVS module.
-- Dave
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
