[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

Richard Bos ml at radoeka.nl
Tue Oct 21 21:02:50 CEST 2008


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




More information about the devel mailing list