kontalk / desktopclient-java

Kontalk official platform independent desktop client
https://www.kontalk.org
GNU General Public License v3.0
57 stars 24 forks source link

Debian package request #23

Open daniele-athome opened 9 years ago

daniele-athome commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

strk commented 9 years ago

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

syamgk commented 9 years ago

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

daniele-athome commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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

pravi commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

petterreinholdtsen commented 7 years ago

Did anyone register a WNPP request for this package? I could not find any. It is the first step for getting a package into Debian. See https://www.debian.org/devel/wnpp/ .

daniele-athome commented 7 years ago

Sorry no request yet. I didn't really had time for it. Issue is currently on hold, honestly I don't know if I'll find the time in the short term. @petterreinholdtsen if you feel up to the task... :-)