Re: Control fields for libraries and programs depending on them
On Tue, Jul 29, 2003 at 08:06:38PM -0400, Neil Roeth wrote:
> Suppose there is a package foobar that depends on a library libfoo. AIUI,
> whenever the SONAME changes, the library name should change, so I expect
> this to evolve as libfoo1, libfoo2, etc. What are the proper control
> fields (Depends, Conflicts, Replaces, Provides) for these packages? If I
> understand correctly, the idea of having different package names for
> libfoo when the SONAME changes is so that libfoo1 and libfoo2 can coexist.
> So, does that mean they should not conflict, and that there should be no
> Replaces or Provides fields in the libfoo2 refering to libfoo1?
Yes. You can find many examples in the packages in the archive.
> I am particularly interested in the case where foobar and libfoo1 are
> installed, and a new version of foobar is released that depends upon
> libfoo2. Should upgrading foobar cause libfoo2 to be installed, but also
> leave libfoo1 installed, since some other package might depend upon it?
Upgrading foobar will require that libfoo2 be installed; it should not have
any direct effect on libfoo1 (though aptitude, for example, will
automatically remove libfoo1 if it only existed to satisfy foobar's
dependency).
--
- mdz
Reply to: