[pkg-kolab] Re: circular dependencies?
Peter Eisentraut
petere at debian.org
Wed Jan 25 11:50:29 UTC 2006
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.
More information about the pkg-kolab-devel
mailing list