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

[Gregory Colpart]

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


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


> 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.
My question is : if patches could be in horde3 Debian package,
why it could not be accepted upstream?


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


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