Rss-bridge: Release for Debian packaging

[josch]

Hi,

I have been running rss-bridge on my server for a while now and it worked well for me. Thus, I'm intending to package it for Debian. I was wondering:

• should I package version alpha 0.2 even though there have been 154 commits since then or will there be another release in the near future?
• the latest version is tagged pre-release even though it seems to work well in practice. Should this deter me from packaging version alpha 0.2 and should I wait with packaging until there is a non-pre-release version?

Thanks!

cheers, josch

[teromene]

Hello,

I think the problem with creating a Debian package is the fact that RSS-Bridge requires a lot of updates, to keep up with the latest website's updates.
So you should pack up the latest version, but please remember that this software will be updated regularly and that it will never really reach a "stable" version.

[josch]

Okay, cool, thanks!

Frequest updates are no problem. We have a very similar situation with other packages that heavily rely on third party websites. Consider the package youtube-dl for example which contains code to download videos from over 700 websites...

[Grummfy]

Packaging for distribution is not so easy and unfortunatelly it require to have some hosting (as I know event on ubuntu with launchpad you require to manually upload you source, etc).

It's something complicated, and to do that you should speak to people who manage things like that like remi (rpm based) https://blog.remirepo.net/ or other people. Because packaging you will require to know what dependency are there : php extension, php version, etc. Then you need to take care of the different license (from your project and the libs you are including with composer and the one from composer itself). ...

[josch]

Hi @Grummfy, maybe I'm misunderstanding you or maybe there are issues with rss-bridge itself that I did not yet encounter but I think I'm aware of all the issues you raise. I'm a Debian project member and I have been packaging software for over 10 years now - this includes also webservices like rss-bridge. You can get an overview of the software I maintain for Debian here: https://qa.debian.org/developer.php?email=josch%40debian.org

But of course I'm always open to suggestions of what to take special care of. And if you want to help then that is of course also greatly appreciated! :)

[Grummfy]

Don't worry, I just prefer to warn people before going crazy about creating package ;) because I know it's not easy to do it.

[arunisaac]

I'm planning to package rss-bridge for Guix. So, it would be very convenient to have a release. Also, it would be good to have rapid release cycles like youtube-dl does. youtube-dl almost has one new release every few days.

https://github.com/rg3/youtube-dl/releases

Thanks for all your work with rss-bridge!

[LogMANOriginal]

An "official" GitHub release is something that takes time to do properly and in this case makes sense for changes to the core framework, which are very rare in comparison to bridge fixes. That being said I do understand the need of having regular releases to keep things up-to-date.

RSS-Bridge is using a rolling release model, where the master branch is considered stable and each commit can be considered a release. I have about zero experience in packaging software, but maybe we can figure out a way to incorporate that into providing packages.

Is there some sort of automation involved based on GitHub workflow, or do you have to build the package manually?
Can you make it work by using the master branch?
Maybe the deployment feature of Travis could also be utilized to automate things

[josch]

I cannot advise you on GitHub related issues as I'm not very familiar with the platform. But I can say that if you decide on a rolling-release model with the master branch considered stable and each commit considered a release, then it is no problem for Debian to use arbitrary git commits as a "release". It would just look ugly in the version number, as that one would include the date and the commit hash. For example the version of the package abci in Debian currently is 0.0~git20170124.0.f94ae5e-2. That's how it would look like for rss-bridge as well if you decide to go that route. Not pretty but doable! :)

Thanks!

[mitsukarenai]

Yeeeaaah well it makes sense RSS-Bridge to use a date-based release versioning like Youtube-dl, 2017.07.21. Just simpler to push updates on a day-to-day rhythm rather than playing around major/minor version bumps depending on core changes, aesthetics, bridge improvements and bridge fixes for syntax, scraping or plain 500 internal error fixing.

[arunisaac]

The Guix project prefers release tarballs to git repositories. Cloning the entire git repo every time a package should be updated is expensive on bandwidth. So, I definitely prefer date-based and frequent releases like youtube-dl.

[josch]

@mitsukarenai date-based release versioning of rss-bridge like youtube-dl is also preferred over using git commits from the master branch by the Debian project. It makes the version numbers look nicer and the release process easier. The same of course also holds true for any downstreams of Debian like Ubuntu or Linux Mint. I cannot speak for other distributinos like Fedora though.

Thanks for your work!

[LogMANOriginal]

RSS-Bridge 2017-08-03 just happened :tada:

Please have a look and let me know if this works for you.

[josch]

@LogMANOriginal it works for Debian! The package will be part of Debian after it clears the NEW queue (out of my hands): https://ftp-master.debian.org/new/rss-bridge_2017-08-03-1.html

[josch]

And rss-bridge is now in Debian:

https://lists.debian.org/debian-devel-changes/2017/08/msg00584.html

[arunisaac]

Thank you! I've initiated packaging in Guix.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27970