[Pkg-giraffe-discuss] tracking of changes done by Kopano Upstream

Simon Eisenmann s.eisenmann at kopano.com
Wed May 2 11:11:02 BST 2018


Hey Carsten,

thanks for your feedback - we discussed today how we can improve the situation for downstream packaging and to simplify tracking of the changes and how we can be more transparent what actually changed in our Kopano packaging. 

-----Original message-----
> From:Carsten Schoenert <c.schoenert at t-online.de>
> Sent: Saturday 28th April 2018 11:35
> To: pkg-giraffe-discuss <pkg-giraffe-discuss at alioth-lists.debian.net>
> Subject: [Pkg-giraffe-discuss] tracking of changes done by Kopano Upstream
> 

> We will need some better communication about what Kopano is planning to
> include as new, changed or removed features in which release otherwise
> it really takes to much time in a longterm to keep tracking all of this.
> Packages provided by Kopano and Debian will divide unnecessarily away to
> much much from each other. These costs have to be payed first by the
> users, something which isn't nice.

So to make tracking of changes easier we are planning to publish our packaging source files to a Git repository which is automatically created from our internal OBS sources. The exact ways have yet to be determined but at the end this repository should have the details of what has changed in packaging. This information is currently not available and thus might provide additional help to simplify downstream packaging. 


> Kopano itself is now providing some Python3 based packages for 8.6.x.
> Also some more tools like the spamd or storeadm. It has taken pretty
> much time on my side to sort out the new things which are now installed.
> And also some time to decide into which package I should integrate the
> new files. There are also some extra new files in /u/sbin which have
> some additional file extension to mark the as Python files which are
> also installed as (php) shell script. For example:
> 
> > usr/sbin/kopano-mr-accept.py: Python script, ASCII text executable
> > root at i5:/tmp/buildd/kopanocore-8.6.1/debian/tmp# file usr/sbin/kopano-mr*
> > usr/sbin/kopano-mr-accept:     a /usr/bin/php script, ASCII text executable
> > usr/sbin/kopano-mr-accept.py:  Python script, ASCII text executable
> > usr/sbin/kopano-mr-process:    a /usr/bin/php script, ASCII text executable
> > usr/sbin/kopano-mr-process.py: Python script, ASCII text executable
> 
> I see what Kopano is wanting to do or is planning here, but wouldn't
> such things better be done in a WIP or beta release instead in a new
> main minor release? Debian isn't like files in /usr/[s]bin with a file
> extension and thus it makes it hard to do a proper packaging here. I
> tried to prepared some updated packages for this but I'm a bit unsure to
> have done it correctly and didn't pushed this to Salsa.

Changes like those should be easier to track with the Git repository mentioned earlier. The situation with the .py files getting installed to usr/sbin is unfortunate and for now has to be handled in packaging. We try to get rid of the php scripts and replace them with their python counterparts and that transition will be complete with 8.7 (unless we find issues).

> 
> And one more thing, I've seen Kopano upstream is providing Python3
> packages like python3-kopano and python3-mapi which is quite nice. As
> far I can see there is no configure option to enable the build of such
> packages. What do we need to create the content for Python3 ready
> packages? As I've understood configure.ac we need to export PYTHON so
> something like /usr/bin/python3.
> Wouldn't it be better to build all available python versions. And as it
> looks like you just change the Shebang it shouldn't be that difficult to
> do this twice for this.

We are discussing if it is possible to use the Python way to build the Python modules instead of the automake based one we currently use. Some Python module related changes have already landed with 8.6 but there is still some way to go. I think it would be best if the python modules could use debhelper via dh_python2 and dh_python3 for their own packaging. 


What do you think?

Best regards
Simon




More information about the Pkg-giraffe-discuss mailing list