Debian packaging #261
Comments
|
(a) As said on IRC, I am willing to support you with this completely -- as far as I can. (b) Have you looked at what we already have in terms of Debian packaging? We actually already do quite a lot: If you run (c) We also have an APT repository here: http://archive.syncany.org/ (d) In terms of dependencies, the Packages file on the APT repo should tell you a lot about the dependencies. (e) What I don't understand is why we would need an extra repo for it with a copy of the code. Can you elaborate on that? (f) Also: Can you elaborate on the general process of getting into the official repos? Is it more like a PPA -- so delivering the source code and they compile for you? Or do you deliver ready made .deb packages? (g) Also: Why would "gradle" be a dependency? Sorry for all the stupid questions. |
|
(a) yay =) (b) Yes! I have imported all of the debian packaging that's already done. The gradle-plugins-thing builds a binary package. You can't build it without the dirty magic that gradle does. It's also a native package (Native packages are debian-only packages like apt-get and such...) So there is alot of work to do! (c) Cool! As I said, you don't have any viable source package so that won't be of any help. When we are done with the Debian packaging, it could be a good idea to replace those .debs with the real .debs that will make it to Debian. That could be great for people that want cutting-edge versions. (d) Your syncany package depends only on Java and no libs. This means your libs are embedded in your jar, which is not the way it works in Debian. Or maybe syncany depends only on the Java standard lib? That would make it very easy. (e) Packaging tools like git-buildpackage will pollute your git repo with branches like pristine-tar that you don't need upstream (take a look at my repo). I will be pushing tags for every debian release (debian/01.12-1) that could confuse people and I will need atleast one more branch (could be called debian) for the actual packaging and debian-related patches. Also, I will need write acces on the repo so I tought that you would prefer a new repo. If you agree with all of the above, it's perfectly fine to use the syncany repo, even prefered. (f) There is no fat-jar that will make it into debian, you cannot embed libs in your software. So ALL of the dependencies have to be packaged into Debian. The source package is the package that creates the .deb. The package maintainer builds a source package and one deb for one architecture. He signs it with his PGP key and the ftp team then accepts it (the ftpteam mainly looks for legal issues). If its accepted, machines of the Debian project will start building for other architectures. In the case of Java packages, there is no point to build more than once, so the maintainer's deb will be the deb that's delivered to every user. About repos. Here are the rules:
In conclusion: (g) Every build dependency has to be in Debian. If there is a prefered way to build without gradle, then I could remove it from the dependencies. The source package is like a recipe that build the .deb with software that is in Debian. In the next few hours, I'll be working on the dependency table. |
|
As said on IRC, feel free to make a suggestion. As long as it can be automated and we can still use gradle to compile, it's all fine. I'll probably reply to your points in detail tomorrow. For reference: This is a Java-based software that is in Debian: https://tracker.debian.org/pkg/jmapviewer -- maybe we/you can look at how they did it. |
|
It cannot be automated (atleast not with Travis). Someone will publish a new version of the package every time syncany is updated upstream, that will be me. If it wasn't clear already, I intend to package syncany. I have filled an ITP. I already maintain other Debian packages. You can take a look at them here. I have just opened the last RFP bugs. I will try to go ahead and package jsemver myself. |
|
(h) For the releases that's fine, but for daily snapshots, can't we at least automate that? (i) Also: Can we call Gradle from the rules file? Is there anything against that? (j) Are packages allowed to download stuff from the Internet during the build process? If so, we should use the Gradle Wrapper (gradlew) to do that. So basically: Create a |
|
(h) Yes you can automate pushing to a PPA, but you cannot automate pushing to Debian. Pushing to Debian is made by humans and will always be. Please DONT give your PGP key to travis. If you want, you can have travis build debs nightly or every commit but that has nothing to do with the official Debian packaging. I will help you setup the nightly builds so that it's as compatible as possible with the official Debian packaging (i) Of course, but we have to call it in offline mode. It cannot pull anything from the web. (j) Never. This could introduce proprietary software in Debian and this would mean that you are trying to build a fatjar. |
|
I am willing to help where I can with this endeavour, but I must say that is a very complex thing you have in mind here. Especially since Gradle automatically downloads dependencies for us, it'll be hard to even compile without doing that... Please let me know how I can help. |
|
Hello, I have recently been accepted in the Debian Java team. I will soon create a repository on Alioth to start packaging jsemver. |
|
I guess congratulations are in order! |
|
@ReAzem Any progress on this? |
|
@binwiederhier It's on hold until the end of my finals ;) I'll resume working on it after. |
|
I have begun working on jsemver here. There is no rush as a new package cannot get into Debian during the freeze, so it is best to work on existing packages. When the freeze ends, I should be able to upload jsemver and hopefully someone manifests interest to package undertow. If not, I'll do it. |
|
👍 |
|
My jsemver package is done and I have opened a Request for Sponsorship. I have updated the table in the first post of this issue. Undertow is now the only missing package. |
|
FYI: Gson & HttpComponents were added. |
|
Wowwwww!!!!!!! Niceeeeeeeee!!!!! |
|
Seems to work nicely: # /etc/apt/sources.list.d/syncany.list
deb http://httpredir.debian.org/debian experimental main
deb http://httpredir.debian.org/debian unstable main
# Install
apt-get update; apt-get install -t experimental syncany |
|
apt pinning is not required for experimental, but here is my preferences file. I have all repos in my lists: stable, testing, unstable, experimental. This preferences file sets my preference to testing. Unless I say otherwise, for example using |
Hello!
I would really like to see syncany in Debian. So I decided to start working on the Debian packaging.
You may follow my work here (If there is interest, we could move the repo to Alioth). My repo uses git-buildpackage.
@binwiederhier If you agree, I think it would be a great idea to move the packaging in the syncany organization. Proper packaging needs to be in a separate repo, a Debian folder won't do it. The repo should be called something like syncany-debian or syncany-gbp.
Because syncany is still in alpha, I think we should push it in the experimental repos.
I don't have any experience in Java maintaining. So I will learn as I go. Feel free to come and help.
Before we start with syncany, I would like us to make a list of all of syncany's dependencies. Feel free to edit my post to document dependencies. If we find dependencies that are not packaged, I will open a Request for Package for each of them.
The text was updated successfully, but these errors were encountered: