> 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
Attachment:
pgpFqzZJTIYno.pgp
Description: PGP signature