tvheadend: 4.2.8 -> 4.3-unstable-2024-08-04 #332259
Conversation
Includes fixes for FFmpeg 7 and compiler warnings. Per their site: > The latest 'stable' release (v4.2.8) was released in January 2019 > and is now showing its age. As there are no plans for another v4.2 > maintenance release and there is no direct upgrade path from v4.2 > to v4.3/v4.4 we recommend all new installs use the current v4.3 > 'development' releases. These have been in a reliable state for > several years and will soon become the new v4.4 stable release (eta > in Q1/2024). It’s not Q1 2024 any more, but let’s take their word for it and drop another FFmpeg 4 pin. RPM Fusion, Gentoo, and OpenWrt all ship the v4.3 development release.
|
There is a patch to 4.2 to fix building with FFmpeg 6, so I may just apply that instead if this turns out to not be viable. But we are going to have to make some kind of decisions here about what to do with this package that’s on a dead‐end version with an incompatible stable release in sight. |
|
You guessed correctly. Unsubscribing. |
|
Bumping this. We are going to have to make a decision about the backwards‐compatibility when 4.4 comes out, and this is one of the very few remaining FFmpeg 4 dependencies that will remain after the rest of my work is merged. Please let me know what you think if you have any investment in this package at all. I worry that there is not enough maintainer attention to sustain this package and that it will end up completely bitrotten. If nobody responds in a timely fashion I will probably just open a PR to drop this package and module. |
|
Hi @emilazy |
|
Thanks for the response, @simonvandel :) As the only remaining package maintainer, would you have any objection to this package and the NixOS module being dropped? It’s a shame, but it seems that there’s nobody in Nixpkgs interested in working on this. Given that the 4.4 release will be a breaking change anyway, maybe it’s best to let users know about the state of things as they stand, and be open to accepting a PR for the newer version if anyone steps up to make one. cc @pyle and @Yarny0 again, as I’d hate to get rid of this package if there’s anyone willing to take responsibility for it. |
|
No objections of dropping the package |
|
Linking #336395 for anyone who might be subscribed to this PR. |
|
Thank you for the response anyway :) Seems like there’s nobody who wants to take care of this, so I’ll probably proceed with removal. |
|
I would like to maintain this |
|
@oneingan That’s good to hear. To get this package into an acceptable maintenance state, we need a plan for getting off the abandoned 4.2 version, as it depends on FFmpeg 4 and the developers recommend users use the 4.3 branch which is intended to become the 4.4 stable release soon. However, 4.3 is apparently backwards‐incompatible with 4.2 and a previous contributor to this package said that it would break the configurations of the majority of users. Can you outline what the expected breakage is here and how difficult it would be for users to migrate to the new version? |
|
Considering tvheadend is configured trough UI, but there is not a clear interface to edit the XML configuration files that UI generates I consider a migration path will be difficult to achieve. I prefer we drop 4.2 and create a new namespace for 4.3~4.4. |
|
That sounds reasonable to me. It seems like the best way forward is to proceed with the PR dropping the existing version for now, then. I’ll be happy to review any PR to add the new version in separately, and you can feel free to base it on this PR as long as you leave a |
|
tvheadend is still a very active project and I'm disappointed that we chose to break existing installs. This is impacting an install of mine. I do understand where you're coming from. Ultimately the best workaround for existing users is probably to migrate to their maintained containers. See: https://github.com/tvheadend/tvheadend/blob/master/Containerfile.alpine |
|
I agree that the upstream project seems active, but the 4.2 branch isn’t, and there’s no migration path to 4.3/4.4, so breaking existing setups was going to be basically unavoidable from what I was able to gather. We will accept a package and module for 4.3 and I will be happy to review it, but the package had no interested maintainers and nobody has done the work yet. The packaging of 4.3 in this PR should be basically ready to go, so if you wanted to maintain it you could make a PR adding it as a new package and check that the module still works with that version; feel free to ping me if you do so. Maybe you and @oneingan could co‐maintain it since it seems there’s hopefully sufficient interest in keeping it running on NixOS? |
Picked up the dropped package config for Tvheadend from NixOS/nixpkgs#332259 and its service config from NixOS/nixpkgs#336395, passed into giants-deep config.
Description of changes
Includes fixes for FFmpeg 7 and compiler warnings. Per their site:
It’s not Q1 2024 any more, but let’s take their word for it and drop another FFmpeg 4 pin. RPM Fusion, Gentoo, and OpenWrt all ship the v4.3 development release.
I’m marking this as a draft because of the “no direct upgrade path from v4.2 to v4.3/v4.4” text from the site. I don’t use this software, so I’m not exactly sure what the implications are here. Perhaps there have been backwards‐incompatible changes in the application state? @melias122 opened a PR to add this version in #168620 and said that “Updating to latest master (aka v4.3) will break configs of most people using v4.2”. I’m wondering if we could perhaps add some logic in the NixOS module to migrate people’s configurations if this is a blocker. There is a source file
src/config.cwhich seems to have a lot of migration functions up toconfig_migrate_v24, but it seems that last one is from 8 years ago, so that probably won’t help us.The fact that another major repository like RPM Fusion is shipping the development version exclusively makes me assume that the migration ought not to be that bad, but I’d really like feedback from someone who actually uses this as to whether the NixOS service still works and doesn’t eat pre‐existing data.
We’d have to decide what to do here when the final v4.4 comes out anyway, especially given that upstream has stated that v4.2 will not receive any more maintenance, so given that upstream recommends new users install v4.3 I think we should figure out what to do now. Unfortunately, it seems like this package has received little non‐automated, non‐treewide attention for years.
cc @simonvandel (maintainer of the package)
cc @pyle (has an open PR to add options to the NixOS module #302304)
cc @Yarny0 (has contributed to
dtv-scan-tableswhich is used exclusively by this package)cc @mweinelt (did a refactor of the package in 2022; sorry if that was just drive‐by)
cc @peterhoeg (did a manual version bump in 2017)
Sorry for the tenuous review pings, this package really hasn’t had many changes that weren’t automated version bumps or people just diving in to fix build issues in many years…
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.