http://blogs.gentoo.org/strerror?disp=comments en-US http://backend.userland.com/rss 60 Tue, 24 May 2005 12:41:09 +0000 Benjamin Smee [Member] c153@http://blogs.gentoo.org/ I don't think it can be done like that. The basic issue is that for each of the component parts kolab has extensive patchsets, so that if I don't somehow lock the subcomponent versions I will be left trying to maintain mammoth patchsets against constantly revving packages. Currently the most elegant way I can think of doing it is to provite a single kolab package that will block its namesakes, at least this way I can effectively version lock, something which portage can't do right now. I am very interested in any ways you can think of to implement it using existing gentoo packages as that is my preferred method as well. I will certainly be staying away from using the openpkg setup they use and I will look to make kolab FHS compliant where possible. http://blogs.gentoo.org/strerror/2005/05/23/hello_world_1#c153 Tue, 24 May 2005 11:24:50 +0000 Christian Parpart [Visitor] c152@http://blogs.gentoo.org/ oh, yeah. please get rid of Kolab in an ideal way - that is, making use of the already existing ebuilds for proftp, apache and co. I'd really like kolab working in, but I dislike the /kolab approach just because they think it's best for them(tm) http://blogs.gentoo.org/strerror/2005/05/23/hello_world_1#c152