Re: Getting rid of circular dependencies
Junichi Uekawa <dancer@netfort.gr.jp> 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
Reply to: