math.parent at gmail.com
Thu Dec 12 03:03:48 UTC 2013
2013/12/10 Paul Klos <kolab at klos2day.nl>:
> Hi all,
> I started work packaging roundcube-plugins-kolab, however I ran into an issue. After I managed to at least get the package to build, I tried installing it on a test VM. I had checked the kolab package, which indicates it depends on roundcube > 0.9, but unfortunately it turned out it actually depends on roundcube > 1.0.
> For Kolab, this is not an issue, because they also ship their own roundcube. But in debian there is only 0.9.5 (in unstable).
> To make matters worse, I have already pushed my commits, so we are now stuck with a 3.1.8 version of roundcube-plugins-kolab, which will only work once roundcube 1.x makes it into debian.
> My git knowledge is not such that I have been able to come up with a solution.
> I can think of starting over completely, importing upstream roundcube-plugins-kolab 3.0.1 and get that to work in Debian first. We could worry about 3.1 later. But this would have some downsides, especially if other people have cloned the repo, which I am not sure of.
I think you should target jessie (rememeber, remember, the 5th of
November). If roundcube 1.0 and all Kolab 3.1 deps can be uploaded to
Debian and migrated to testing before November 5, then do the
- create a upstream-3.0 (or a better name) branch starting from the
last 3.0 commit
- create a debian-3.0 (or a better name) branch starting from the last
- adjust debian/gbp.conf branch names
But: I can't find your commits on git.debian.org. Have you done it already?
> Is there any more intelligent solution to this situation?
Going backward is a solution also. Mabe cleaner (and people cloning
the repo are probably following this list).
More information about the pkg-kolab-devel