On Monday, February 25, 2002, at 07:58 , David R. Morrison wrote:
> Kyle Moffett <[EMAIL PROTECTED]> wrote:
>
>> On Monday, February 25, 2002, at 11:20 , David R. Morrison wrote:
>>> Packages containing both binary files and libraries
>>>
> [snip]
>>
>> I would recommend that the foo package not be foo3. I think that since
>> we can only have one foo headers package installed at a time, it would
>> be a lot easier for conflicts and replaces to have just foo.
>>
>
> This doesn't work. Let's say that foo3 has just been released, and you
> have 10 installed packages which depend on the foo2 library. We have
> to wait for the maintainers of those packages to update from foo2 to
> foo3, because the incompatible API might cause breakage which the
> maintainer has to deal with. In the meanwhile, the maintainer might
> still update the old package to a new version, still depending on foo2.
>
> So you have to have the ability to load foo2 or foo3 depending on which
> package you are compiling at the moment. When you load foo2, a symlink
> is created: libfoo.dylib -> libfoo.2.dylib so that all compiles link
> to version 2. Later if you load foo3, you get libfoo.dylib ->
> libfoo3.dylib and the links are made with version 3. Even later you
> might need to reload foo2 again to compile a different package.
The package maintainers should do something like:
BuildDepends: foo
Depends: foo2-shlibs
Then they don't care about foo, because the version needed already
depends on foo2-shlibs (I think that will work)
Or even if it doesn't work, then:
BuildDepends: foo (>= 2.0.0 <<3.0.0)
Depends: foo2-shlibs
I think thats the right syntax anyway.
The big problem here is the Replaces and Conflicts. For four versions
of some package, are we going to have this?
foo2
Conflicts: foo3, foo4, foo5
Replaces: foo3, foo4, foo5
foo3
Conflicts: foo2, foo4, foo5
Replaces: foo2, foo4, foo5
foo4
Conflicts: foo2, foo3, foo5
Replaces: foo2, foo3, foo5
foo5
Conflicts: foo2, foo3, foo4
Replaces: foo2, foo3, foo4
This is ridiculous for four versions of a library. If we combine the
header package names we can take advantage of already written code in
fink, namely the versioning and version replacement system, where stuff
conflicts with earlier and later versions of itself.
> [snip]
>
>>> Upgrading presents a problem in this situation, however, since users
>>> won't
>>> be prompted to install <code>foo-bin</code>. To work around this,
>>> until
>>> all other package maintainers have revised their packages as above,
>>> your <code>foo</code> package can say
>>> <codeblock>
>>> Depends: foo-shlibs (= exact.version), foo-bin
>>
>> Here I disagree, since foo3-shlibs and foo4-shlibs represent an
>> incompatable api change, any programs should be the same version as the
>> libraries, therefore foo-bin should: Depends: foo-shlibs (== %v).
>> Also,
>> just like plain old foo header packages, foo-bin should not have the
>> version in the packagename (Many of them will probably have the same
>> files in them).
>>
>
> Absolutely, the long-term goal is that foo-bin depends on foo-shlibs.
> The recommendation here is for the transition period, and it solves the
> problem which Martin Costabel noticed: when you upgrade, foo-bin might
> not be loaded on your system, even if it is needed by other packages.
> Until the other package-maintainers fix this, you can let foo depend
> on foo-bin (temporarily).
Oops, I just realized I forgot to include my alternative. Sorry! =)
I would recommend that,
foo
Version: 3.1.2
Depends: foo3-shlibs
BuildDepends: foo-bin
foo-bin
Version: 3.1.2
Depends: foo3-shlibs
With the builddepends, the binaries could be removed later if the user
didn't want them, otherwise, they would be reinstalled every time foo
was.
>
> As far as the naming goes, I disagree again. Of course foo2-bin and
> foo3-bin will conflict and people will have to decide which one they
> want at runtime. Ultimately (once the long-term goal is achieved)
> this won't affect your ability to switch back and forth between foo2
> and foo3 (the header packages) whenever you need to.
I would like to point out that this tim, the Conflicts and Replaces
lines begin to get ridiculous if you have four different versions of
some library available
> -- Dave
IMHO,
Kyle Moffett
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
