[pkg-horde] (Sort-of) forking Horde for Kolab?

Sun Nov 8 11:32:41 UTC 2009

(Gunnar, I'm cc-ing this to you as I am talking about you. Maybe you
can give more precisions. See "why it could not be accepted
upstream?")

Hello,

On Sun, Nov 8, 2009 at 2:06 AM, Gregory Colpart <reg at evolix.fr> wrote:
> Hello,
>
> On Thu, Nov 05, 2009 at 09:29:16PM +0100, Mathieu Parent wrote:
>> >
>> > Note that "upstream+patches" branch is not really usable.
>> What do you mean by not really usable. Don't you use "git merge"?
>
> No. "upstream+patches" branch is here for git-format-patch in
> debian/rules to generate debian/patches/.*

OK.

I hope that my misunderstanding has not created incorrect packages, as
I have merged as said.

For example: http://git.debian.org/?p=pkg-horde/turba2.git;a=commitdiff;h=f6d45a34458d783052b3195e6d42a70df959cb0e

>> > If you create a "kolab-webclient" branch, it's the same problem.
>> > How do you plan to deal with new upstream release?
>> > And what is the goal of the branch? Create a new package
>> > with duplicated source code? I hope it's not!
>> The goal of this branch is not to create new packages. The branches
>> will be linked like this (using git merge):
>>
>> upstream -> upstream+repack -> upstream+patches -> kolab -> debian-sid
>>
>> when a new release happen, we (as horde packagers) will push it into
>> upstream. then:
>> git checkout upstream+repack
>> git merge upstream
>> git checkout upstream+patches
>> git merge upstream+repack
>> git checkout kolab
>> git merge upstream+patches
>> git checkout debian-sid
>> git merge kolab
>
> As I said above, workflow is not exactly like you describe:
> "upstream+patches" branch is not merged in "debian-sid".
> But it's not an essential point.

Yes, those patches can be included in the upstream+patches (u+p)
branch or in a kolab branch merged in u+p.

>
>> Resolving conflicts if needed. The diff.gz will be identical as "git
>> diff upstream+repack..debian-sid".
>> All the kolab specific patches (except config) will go in the kolab
>> branch (they also will be shown in debian-sid because of the merge)
>> The split of packages (app and app-config) will go in branch debian-sid.
>>
>> Each change to the kolab branch will be documented in the
>> debian/changelog of debian-sid.
>
> Ok. Then you want push kolab specific patches to horde3 source
> packages. I prefer to keep only one "patches" branch.
ok

> My question is : if patches could be in horde3 Debian package,
> why it could not be accepted upstream?

The process of integrating those patches is ongoing. Gunnar Wrobel
(who is also the gentoo packager for kolab) is pushing those patches
and an amazing job has already been made. See
http://github.com/wrobel/horde-release/blob/t/KOLAB/STATUS

The remaining patches have not been accepted for various reasons, mainly:
- not submitted yet (Gunnar want to clean them a bit, or they are too new)
- rejected because they don't respect horde coding guidelines and
should be implemented in a better but more intrusive way.

Gunnar is currently working on implementing those patches (and others)
in upstream Horde4.

The remaining patches are not critical ones, so kolab-webclient will
be functionnal without (and also some of them are already integrated
as kolab usptream uses horde-webclient 1.2.0 instead of 1.2.4)

>> >> There is a special kind of patches which are "Config" patches. My
>> >> proposal for those is as follow:
>> >> - split all horde packages (app=imp4,kronolith2, horde3, ...) into app
>> >> and app-config.
>> >>   * app-config will contain all the /etc part and examples config.
>> >>   * app will depend on app-config (= ${source:Version}) | app-config-custom
>> >>   * app-config will conflicts with app-config-custom and recommends app
>> >> - the kolab-weblient package will provide app-config-custom, conflicts
>> >> with app-config
>> >> - all those packages will pass through the new queue.
>> >>
>> >> => Is this OK for horde packagers?
>> >
>> > I'm not sure to understand: what is your kolab-webclient package?
>> > Is it *only* for providing custom config? Seems overkill...
>>
>> Upstream kolab-webclient is horde-webclient+patches (features and configs).
>> I see Debian's kolab-webclient as a set of conffiles and maintainers
>> script (to setup db, ...). See [kwc]
>> The feature patches will be integrated in pkg-horde-hackers's packages
>> like said above.
>>
>> This seems unnecessary a so "tiny" package, but it is important to
>> allow easy installation of kolab-webclient without duplication of
>> code. Also the mechanism provided here can be used for other types of
>> preconfiguration like "Horde Groupware" [gw] or "Horde Groupware
>> Webmail Edition" [wm].
>>
>> [kwc] http://packages.debian.org/experimental/all/kolab-webclient/filelist
>
> I'm very not convinced this is the solution to allow easy
> installation. .sql files could go to classic packages. And
> conf.php files are conffiles generated by Horde webadmin, and
> I think we could find ideas to have an easiest installation (if
> really needed) without creating dozen of new binary packages...
I agree. So tiny packages is not good.

While reading http://www.debian.org/doc/debian-policy/ch-files.html#s10.7.4
(Sharing configuration files), i thought about using alternatives.

horde3 will provide an alternative: "horde-config" defaulting to
/etc/horde/horde3 and /usr/share/horde/config will point to this
alternative.
Same for imp4, turba2, kronolith2, ... (all horde packages)

horde3 will also provide another alternatives for horde-config,
imp-config, ... with smaller priority that will point to
/etc/kolab-client/appN.

With this solution, no new package is needed as the kolab-webclient
configs are included in horde3.

Summary:
- use alternatives for appN-config, defaulting to /etc/horde/appN
provided by package appN (no new package needed)
- horde3 provides  also /etc/kolab-webclient/appN directories (foreach
appN), with a lower alternative priority for appN-config (files
maintained by pkg-kolab members)
- include kolab patches in Debian Horde packages one by one (as
needed) in upstream+patches branches

Gregory, does this sounds better to you ? Does this sounds good enough ;) ?

> Regards,
> --
> Gregory Colpart <reg at evolix.fr>  GnuPG:1024D/C1027A0E
> Evolix - Informatique et Logiciels Libres http://www.evolix.fr/
>

Mathieu Parent