> 1) foo and foo-data. There is usualy no reason for foo-data to depend on > foo. foo-data does not provide user-visible interface, only data, so it > does not need to depend on foo.
However, we have some users randomly filing bugs on
foo-data that doesn't get uninstalled if it's no longer useful.
We need
1. policy documenting the current decision that foo-data doesn't depend on foo
2. helper information to allow tools like deborphan to work correctly.
> 2) libfoo and foo-bin, where foo-bin include binaries linked with
> libfoo. Usually libfoo only need to Depends on configuration data
> in foo-bin and not on any binaries linked with libfoo (to avoid infinite
> recursion). In that case it should be possible to split foo-bin in
> foo-bin and foo-common, and change libfoo to depend on foo-common
> instead.
I'm rather doubtful it should be easy to fix this situation.
I doubt having configuration data in foo-bin is a good idea,
since it will generally cause problems when
libfoo1/libfoo2 needs to coexist.
regards,
junichi
--
Junichi Uekawa, Debian Developer http://www.netfort.gr.jp/~dancer/
183A 70FC 4732 1B87 57A5 CE82 D837 7D4E E81E 55C1
pgpHnflZrU25P.pgp
Description: PGP signature
