Debian package request

[daniele-athome]

I'm going to begin hunting for a sponsor to include us in Debian. Of course we'll wait for you @alex until you say that the client is stable enough for inclusion. In the meantime I'll setup the required scripts and all the stuff needed to make the package. Maybe, and I say maybe, by being a FSFE member I might have a chance.

[abika]

Ok, thanks! But I'm still a bit unsatisfied with the current development status and it will take at least some weeks and another pre-release until stable.

[daniele-athome]

No problem. I'll begin working on it, there is no hurry. We'll have to wait a long time anyway :-)

[strk]

@daniele-athome is JDK version an obstacle ? See #31

[syamgk]

currently maintaining package repository at
https://gitlab.com/syamgk/kontalk

[daniele-athome]

You are keeping a fork of the project right now. Could you develop patches or a set of scripts (or even upstream patches in safe way) for not forking the entire repository?

[pravi]

@daniele-athome it is not a fork, we are not going to make any upstream changes there. That is the standard way of packging, take tarballs from upstream and maintain only 'debian' directory in a repo. Keeping upstream code in the repo is for convenience only.

[daniele-athome]

I know you don't modify the code, but wouldn't be more maintainable to keep only the debian files and use a script or something to download the sources? I don't know how you do it usually, it's just that it doesn't seem much benificial for you and for us... wouldn't it be better to merge those debian rules to upstream directly? As long as #49 is solved...

[pravi]

@daniele-athome , this is the standard practice, see http://anonscm.debian.org/cgit/pkg-java/ every project keeps a copy of upstream. Earlier people used to keep only debian folder in the repo. Now people seem to prefer the whole repository structure. By keeping it in pkg-java repo, everyone in the pkg-java team has commit access to it, if you are merging it here, every change has to come with a pull request. We usually work with released tarballs and we can't change debian folder here after the release, that will have to go to next release. Any change to the debian package will have to wait for a new upstream release. It will add restrictions to both upstream and debian changes.

[daniele-athome]

Fair enough. @abika what do you think? I'll leave the decision to you.

[pravi]

@daniele-athome, there is also an option of making it a native debian package, but usually only debian specific tools are done this way. In such cases core code and packaging is done in a single repository. We can try that route if you feel maintaining debian folder here is better.

[abika]

What exactly is the question? We should leave the Debian packaging to the Debian community, they know best how to do it. And I'm happy they are willing to provide a package for this humble Desktop client project.)

[daniele-athome]

That's exactly the question :-) whether to include the debian directory upstream or let the Debian project maintain it (in other words, let us handle the packaging or not).

[strk]

It's useful to leave packaging to others, but it'd also be nice to be able to build a custom package for a development snapshot (for example).