[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

> regards,
> 	junichi


Reply to: