[Kolab-devel] Native Packaging, Issue Tracking & Restructuring the SCM

[Thomas Arendsen Hein]

* Gunnar Wrobel <wrobel at kolabsys.com> [20100909 10:49]:
> Zitat von "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:
> 
> > Gunnar Wrobel wrote:
> >> Zitat von "Jeroen van Meeuwen (Kolab Systems)" <vanmeeuwen at kolabsys.com>:
> >     http://git.kolabsys.com/kolab-utils.git/tree/
> 
> I didn't take a close look at the repo now but it makes sense to me to  
> split this into a library and a utilities part.

Here the danger is even higher that code has to be moved between
utilities and libraries when the libraries become more capable of
doing what currently might be duplicated code in the utilities.

> I don't feel we need to keep these in a repository. But I think you  
> are rather close to the cyrus upstream development, right? So it might  
> make sense for you to rebase the patches often. What I did so far was  
> to have a small Makefile that allows me to rebase the patches to a new  
> release (see  
> http://kolab.org/cgi-bin/viewcvs-kolab.cgi/server/imapd/patches/).

New URL: http://hg.kolab.org/server/file/default/imapd/patches/

> >> > - native packaging from tarball releases.
> >>
> >> I think most devs agree this is a desireable target for 2.3. Again we
> >> are talking about two - three packages here.
> >>
> >
> > Not entirely true, I think; the patches we ship, or have shipped, are not all
> > of them fully integrated upstream yet (php, cyrus-imapd), or have  
> > not yet been
> > adopted in a released version of the distribution native packages. Or,
> > sometimes, our product is not ready to handle by better implementing the
> > required functionality (getgrent patch, ldap uid patch).
> 
> Ah, so you want to release a modified tarball for the patched  
> components as well? Never thought about this and always assumed the  
> patching should be done within the package definition. Actually I  
> still believe this is better because it allows the downstream distro  
> to decide whether they want to have the patches in the main package or  
> not. Sure, we had problems to get the cyrus patches in in Debian or  
> Suse. But they were available in the Gentoo package for example. If we  
> release our own tarball then this wouldn't be possible anymore. Or at  
> least harder.

I think you can just read the original sentence for the patched
components as: "Native packages with out patches included".
Much like the current OpenPKG packages, but not for OpenPKG.

Regards,
Thomas

-- 
thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner