Junichi Uekawa <[EMAIL PROTECTED]> writes: >> 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 already have debfoster, deborphan and aptitude for this. Also this applies for libfoo much for than for foo-data packages. That is a larger problem with existing solutions. > We need > > 1. policy documenting the current decision that foo-data doesn't depend on foo Policy already forbids circular depends. > 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. Might be problematic for multiarch too. You need 32bit and/or 64bit libfoo packages but only one foo-bin package (usualy). The configuration will have to work for one or the other or both at the same time. But usualy that isn't a problem. It just needs to be thought off and might force some of the suggested splits into libfoo, foo-bin and foo-common. > regards, > junichi MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]