[pkg-kolab] Re: circular dependencies?

[Benjamin Seidenberg]

> 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.
>

Ah. I didn't pay attention to the (= ${Source-Version})

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

This could be quite confusing to people who don't intend to install kolab.

>
> 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.
>

I don't know that this is acceptable for policy, if they have the same
files, aren't they required to conflict?

> 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.
>
>

Why does it suck to fork the entire thing? It's all one source package, so
it's just a few extra build steps. Actually, I would think it'd be easier
to fork the entire source package than to split it up anyway. Sven has
offered to let you use the SVN repository, so it'd simply be a matter of
keeping an extra branch, and whenever we make a change do an svn merge. I
think it'd be simplest to fork the whole thing, and just maintain it in
parallel. I could be wrong though.

Benjamin