[Kolab-devel] gunnar: server/perl-kolab/bin kolab_bootstrap.in , NONE, 1.1 kolabcheckperm.in, NONE, 1.1 kolabconf.in, NONE, 1.1 kolabdcachetool.in, NONE, 1.1 kolabd.in, NONE, 1.1 kolabpasswd.in , NONE, 1.1 kolabquotareport.in, NONE, 1.1 kolabquotawarn.in, NONE, 1.1 kolab_smtpdpolicy.in, NONE, 1.1 kolab_upgrade.in, NONE, 1.1

[Gunnar Wrobel]

Quoting Richard Bos <ml at radoeka.nl>:

> Op Tuesday 21 October 2008 11:48:05 schreef Gunnar Wrobel:
>> Quoting Richard Bos <ml at radoeka.nl>:
>> > Hi,
>> >
>> > Op Friday 10 October 2008 16:22:07 schreef cvs at kolab.org:
>> >> Update of /kolabrepository/server/perl-kolab/bin
>> >> In directory doto:/tmp/cvs-serv20319/bin
>> >>
>> >> Added Files:
>> >>         kolab_bootstrap.in kolabcheckperm.in kolabconf.in
>> >>         kolabdcachetool.in kolabd.in kolabpasswd.in
>> >>         kolabquotareport.in kolabquotawarn.in kolab_smtpdpolicy.in
>> >>         kolab_upgrade.in
>> >> Log Message:
>> >> Merge all perl tools into the perl-kolab package.
>> >
>> > why did this happen?  Don't belong those tools/scripts whatever to the
>> > kolab server?
>>
>> The Kolab Server is a set of many different packages. It requires
>> postfix, cyrus but also perl-kolab, kolabfilter and kolabfreebusy.
>
> Yep.
>
>> You are referring to the kolabd package. What did and does the package
>> deliver?
>>
>>   - bash scripts
>>   - perl scripts
>>   - configuration templates
>>   - amavisd templates
>>
>> Especially the scripts are a wild assortment of different
>> functionality that "do something for the server".
>>
>> I consider it essential in packaging to use the language specific
>> packaging tools. This would be PEAR for php, MakeMaker for Perl,
>> distutils for python and gem for Ruby.
>>
>> So the change was not at all about perl-kolab but in fact about
>> cleaning up the kolabd package. We need to get rid of the distconf
>> approach in the long run and this has been just another commit on the
>> road to that goal.
>
> I see.  Good goal.
>
>> I wouldn't mind if we place these perl scripts into a seperate perl
>> package (maybe "perl-kolab-scripts") if you consider that more
>> appropriate. I only moved all that stuff into perl-kolab and also
>> collapsed kolabconf into perl-kolab for convenience.
>
> I always thought that it should some how be possible that others (outside
> kolab) should be able to install perl-kolab module.

Absolutely. This is the intention. The easiest way to achieve that is  
to build a clean perl package that uses Make::Maker (the Makefile.PL  
in server/perl-kolab/).

> If that is true, all the
> scripts that you added to the perl-kolab module are strangers to the module
> and it would indeed better to have them moved to another package.

Each and every one of the perl-based scripts actually requires  
perl-kolab as a basis. So I don't consider them strangers to the  
package at all. But as Thomas did also complain I'll probably move  
them some where else later. I actually don't care much about the  
actual structure. It is just important that we use packing tools that  
work across the distributions. And in case of Perl Make::Maker is the  
standard.

Cheers,

Gunnar

> Don't know
> whether the scripts should be stored in perl-kolab-scripts, might be good
> indeed, but it also results in package fragmentation.
>
>> The very critical part about the change was the use of MakeMaker (or
>> Makefile.PL) which I consider essential. The scripts don't use the
>> dist_conf approach any longer but use the Kolab configuration files
>> which is how they should work.
>
> :)
>
>> > Why should e.g. kolab_bootstrap.in be part of perl-kolab and not of
>> > the kolab server package?  If kolab_bootstrap.in is going to be rewritten
>> > in bash, ruby, python, should it than be moved to respectively
>> > bash-kolab, ruby-kolab or python-kolab?
>>
>> Not at all. From a packaging perspective I wouldn't mind if we get
>> packages such as kolabconf (which I collapsed into perl-kolab now),
>> kolabbootstrap, kolabd-daemon and so on.
>
> That looks to fragmented to me.  Those scripts are all essential to the kolab
> server, as such I would put them all in the "kolab" package.  I will see  how
> it goes.  I hope I can follow what is going on.
>
>
>> But this is usually not the
>> way things are handled on OpenPKG. In most cases packages bundle
>> different type of funtionality.
>>
>> Cheers,
>>
>> Gunnar
>>
>> > With all scripts removed from the kolab package, the latter is now almost
>> > an empty package...
>> >
>> > --
>> > Richard Bos
>> > We are borrowing the world of our children,
>> > It is not inherited from our parents.
>> >
>> > _______________________________________________
>> > Kolab-devel mailing list
>> > Kolab-devel at kolab.org
>> > https://kolab.org/mailman/listinfo/kolab-devel
>
>
>
> --
> Richard Bos
> We are borrowing the world of our children,
> It is not inherited from our parents.
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/devel/attachments/20081027/70d7ba63/attachment.sig>