Max Horn [[EMAIL PROTECTED]] wrote:
> I just added code to CVS that enables initial splitoff support. All
> brave developers please go ahead and install it and test how it
> works. To do so, check out the "fink" CVS module and use the
> inject.pl script.
Other than my libtool versioning issue (which isn't fink's fault),
I've had 0 problems converting my rrdtool package over to splitoff
format -- it works great. Thanks, Max!
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)
dpkg will install multiple versions of rrdtool-shlibs, right?
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.
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.
Is this something that needs to be reexamined now that split packages
are a reality?
--
Ben Reed a.k.a. Ranger Rick ([EMAIL PROTECTED])
http://defiance.dyndns.org/ / http://radio.scenespot.org/
...if humanoids eat chicken, then obviously they'd eat their own
species. Otherwise they'd just be picking on the chickens. -- Kryten
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
