[pkg-kolab] Re: circular dependencies?

[Peter Eisentraut]

Benjamin Seidenberg wrote:
> Eh? Nothing depends on cyrus-pop3d-2.2, thus no circle. It's only
> dependency is the common package. Just have your packages
> conflict/provide/replace the -common package and it shouldn't be an
> issue, if I'm understanding it right. Could you provide a bit more
> detail?

Perhaps Steffen was a little unclear, so allow me to explain.  During 
the packaging of the kolab fork of cyrus it has turned out that we 
would really only need to fork the packages -common, -imapd, and 
lib...perl; the other packages would just be the same.  So we are 
trying to work out a way in which a kolab installation would pull in 
the three forked packages plus the additional original cyrus packages 
that it requires.

One instance of the problem we are facing is this:

Package: cyrus-pop3d-2.2
Depends: cyrus-common-2.2 (= 2.2.12-2)

Here, an original cyrus package depends on a package that kolab would 
need to fork.

We cannot work around this by a Provides because the dependency is 
versioned and would thus not consider virtual packages.  You could 
remove the versioning, but that obviously has other drawbacks.

You could add | kolab-cyrus-common to the dependency, but it's not clear 
whether that is optimal either.

One plan that I have thought of is that kolab-cyrus-common would Replace 
but not Conflict with cyrus-common-2.2, thus allowing them both to 
exist on the system to satisfy the various dependencies.  But that 
setup sounds pretty weird and would need more careful consideration.

The final workaround is to repackage everything including -pop3d, 
-admin, etc. merely to adjust the dependencies, but that obviously 
sucks.

We're interested in suggestions on this matter.