10.6.0 RPM doesn't update previous versions

backuprepo commented

2025-12-21 19:46:44 +01:00

Owner

Originally created by @brianjmurrell on GitHub (Jul 25, 2020).

Because there is no %files section in the jellyfin.spec no jellyfin package is produced and only a jellyfin-server package is produced. This leaves RPM with nothing to do. The jellyfin package is needed so that it upgrades an existing/installed jellyfin package and that brings in the jellyfin-server package.

Originally created by @brianjmurrell on GitHub (Jul 25, 2020). Because there is no `%files` section in the `jellyfin.spec` no _jellyfin_ package is produced and only a _jellyfin-server_ package is produced. This leaves RPM with nothing to do. The _jellyfin_ package is needed so that it upgrades an existing/installed _jellyfin_ package and that brings in the _jellyfin-server_ package.

backuprepo

2025-12-21 19:46:44 +01:00

closed this issue
added the
bug

build
labels

backuprepo commented

2025-12-21 19:46:49 +01:00

Author

Owner

@mooninite commented on GitHub (Jul 30, 2020):

There is no need for an empty Jellyfin package. The fix is to add a Provides/Obsoletes pair to jellyfin-server.

Obsoletes: jellyfin < 10.6.0
Provides: jellyfin = %{version}-%{release}

@mooninite commented on GitHub (Jul 30, 2020): There is no need for an empty Jellyfin package. The fix is to add a Provides/Obsoletes pair to jellyfin-server. Obsoletes: jellyfin < 10.6.0 Provides: jellyfin = %{version}-%{release}

backuprepo commented

2025-12-21 19:46:52 +01:00

Author

Owner

@brianjmurrell commented on GitHub (Jul 30, 2020):

There is no need for an empty Jellyfin package. The fix is to add a Provides/Obsoletes pair to jellyfin-server.

That does not meet the goal of separating the server out into it's own package as I understand it.

My understanding is that the future jellyfin package is to be the webUI separated from the jellyfin-server package such that one can install just jellyfin-server if they want just the server with no webUI or they can install jellyfin which will install both the jellyfin-server as well as the webUI package.

So the (currently) empty (it's in fact called a meta-package) jellyfin package needs to be preserved until all of the above is finally accomplished and future users should just continue to allow the jellyfin package to upgrade without having to have a manual/flag-day event where users have to manually fiddle with package installation to overcome a non-backwards compatible packaging change.

Can you please confirm if my understanding of the path forward is correct @joshuaboniface?

@brianjmurrell commented on GitHub (Jul 30, 2020): > There is no need for an empty Jellyfin package. The fix is to add a Provides/Obsoletes pair to jellyfin-server. That does not meet the goal of separating the server out into it's own package as I understand it. My understanding is that the future jellyfin package is to be the webUI separated from the jellyfin-server package such that one can install just jellyfin-server if they want just the server with no webUI or they can install jellyfin which will install both the jellyfin-server as well as the webUI package. So the (currently) empty (it's in fact called a meta-package) jellyfin package needs to be preserved until all of the above is finally accomplished and future users should just continue to allow the jellyfin package to upgrade without having to have a manual/flag-day event where users have to manually fiddle with package installation to overcome a non-backwards compatible packaging change. Can you please confirm if my understanding of the path forward is correct @joshuaboniface?

backuprepo commented

2025-12-21 19:46:54 +01:00

Author

Owner

@mooninite commented on GitHub (Jul 30, 2020):

There is no need for an empty Jellyfin package. The fix is to add a Provides/Obsoletes pair to jellyfin-server.

That does not meet the goal of separating the server out into it's own package as I understand it.

My understanding is that the future jellyfin package is to be the webUI separated from the jellyfin-server package such that one can install just jellyfin-server if they want just the server with no webUI or they can install jellyfin which will install both the jellyfin-server as well as the webUI package.

Then add the Obsoletes/Provides and a Requires: jellyfin-server into the jellyfin-web package.

When someone types in "dnf install jellyfin" it will drag in the jellyfin-web package (Provides: jellyfin) and jellyfin-server package.

So the (currently) empty (it's in fact called a meta-package) jellyfin package needs to be preserved until all of the above is finally accomplished and future users should just continue to allow the jellyfin package to upgrade without having to have a manual/flag-day event where users have to manually fiddle with package installation to overcome a non-backwards compatible packaging change.

It does not need to be preserved. If this helps convince you: I'm a 10+ year Fedora packager that maintains dozens of packages. I'm aware of all sorts of cases of package retirement and renaming that are explained in Fedora packaging guidelines. I'll list the particular guidelines for this case.

https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages

@mooninite commented on GitHub (Jul 30, 2020): > > There is no need for an empty Jellyfin package. The fix is to add a Provides/Obsoletes pair to jellyfin-server. > > That does not meet the goal of separating the server out into it's own package as I understand it. > > My understanding is that the future jellyfin package is to be the webUI separated from the jellyfin-server package such that one can install just jellyfin-server if they want just the server with no webUI or they can install jellyfin which will install both the jellyfin-server as well as the webUI package. Then add the Obsoletes/Provides and a Requires: jellyfin-server into the jellyfin-web package. When someone types in "dnf install jellyfin" it will drag in the jellyfin-web package (Provides: jellyfin) and jellyfin-server package. > So the (currently) empty (it's in fact called a meta-package) jellyfin package needs to be preserved until all of the above is finally accomplished and future users should just continue to allow the jellyfin package to upgrade without having to have a manual/flag-day event where users have to manually fiddle with package installation to overcome a non-backwards compatible packaging change. It does not need to be preserved. If this helps convince you: I'm a 10+ year Fedora packager that maintains dozens of packages. I'm aware of all sorts of cases of package retirement and renaming that are explained in Fedora packaging guidelines. I'll list the particular guidelines for this case. https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages

backuprepo commented

2025-12-21 19:46:57 +01:00

Author

Owner

@brianjmurrell commented on GitHub (Aug 27, 2020):

@joshuaboniface Can you please clarify your vision of various Jellyfin installs? Is the idea that just the server can be installed on one machine and just the webUI on another, or does the webUI machine require the server to be on the same machine?

@brianjmurrell commented on GitHub (Aug 27, 2020): @joshuaboniface Can you please clarify your vision of various Jellyfin installs? Is the idea that just the server can be installed on one machine and **just** the webUI on another, or does the webUI machine require the server to be on the same machine?

backuprepo commented

2025-12-21 19:47:01 +01:00

Author

Owner

@dkanada commented on GitHub (Aug 27, 2020):

You can install the web client anywhere as long as you use the standalone installation. I'm not sure where exactly that flavor stands though because we might have rolled some things back for the latest stable version, @MrTimscampi might know.

@dkanada commented on GitHub (Aug 27, 2020): You can install the web client anywhere as long as you use the standalone installation. I'm not sure where exactly that flavor stands though because we might have rolled some things back for the latest stable version, @MrTimscampi might know.

backuprepo commented

2025-12-21 19:47:04 +01:00

Author

Owner

@brianjmurrell commented on GitHub (Aug 27, 2020):

So there needs to be the following packages then, yes?

jellyfin-server: server
jellyfin-ui: web-ui
jellyfin: meta-package that installs jellyfin-server and jellyfin-ui

so that a given installation could be number 1 installed on one machine and number 2 on another, but in a different installation number 3 could be installed on a single server that is combination of 1 and 2.

Is my understanding correct?

@brianjmurrell commented on GitHub (Aug 27, 2020): So there needs to be the following packages then, yes? 1. jellyfin-server: server 2. jellyfin-ui: web-ui 3. jellyfin: meta-package that installs jellyfin-server and jellyfin-ui so that a given installation could be number 1 installed on one machine and number 2 on another, but in a different installation number 3 could be installed on a single server that is combination of 1 and 2. Is my understanding correct?

backuprepo commented

2025-12-21 19:47:06 +01:00

Author

Owner

@dkanada commented on GitHub (Aug 27, 2020):

That's indeed the goal. I'm actually migrating my web client as we speak to a VPS for better speeds.

@dkanada commented on GitHub (Aug 27, 2020): That's indeed the goal. I'm actually migrating my web client as we speak to a VPS for better speeds.

backuprepo commented

2025-12-21 19:47:08 +01:00

Author

Owner

@heyhippari commented on GitHub (Aug 27, 2020):

You can install the web client anywhere as long as you use the standalone installation. I'm not sure where exactly that flavor stands though because we might have rolled some things back for the latest stable version, @MrTimscampi might know.

Setup wizard and plugin config pages don't work. Most of the rest should be good.

@heyhippari commented on GitHub (Aug 27, 2020): > You can install the web client anywhere as long as you use the standalone installation. I'm not sure where exactly that flavor stands though because we might have rolled some things back for the latest stable version, @MrTimscampi might know. Setup wizard and plugin config pages don't work. Most of the rest should be good.

backuprepo commented

2025-12-21 19:47:10 +01:00

Author

Owner

@brianjmurrell commented on GitHub (Aug 27, 2020):

That's indeed the goal

So that would seem to contradict @mooninite's suggestion of having jellyfin-server Obsoletes/Provides: jellyfin. Anyone disagree?

@brianjmurrell commented on GitHub (Aug 27, 2020): > That's indeed the goal So that would seem to contradict @mooninite's suggestion of having jellyfin-server `Obsoletes/Provides: jellyfin`. Anyone disagree?

backuprepo commented

2025-12-21 19:47:12 +01:00

Author

Owner

@joshuaboniface commented on GitHub (Aug 27, 2020):

I'm not adverse to this working somewhat differently for Fedora/CentOS vs. Debian - if it makes more sense in RPM-land to have an Obsoletes/Provides instead of an empty package, we can do that. I realized far too late that Debian could do the same thing, and it would save an additional step in the build scripts.

The main goal is just to have dnf install jellyfin install both jellyfin-server and jellyfin-web, and ensure that both of those packages can be build independently (i.e. no cross-dependencies at build time).

@joshuaboniface commented on GitHub (Aug 27, 2020): I'm not adverse to this working somewhat differently for Fedora/CentOS vs. Debian - if it makes more sense in RPM-land to have an Obsoletes/Provides instead of an empty package, we can do that. I realized far too late that Debian could do the same thing, and it would save an additional step in the build scripts. The main goal is just to have `dnf install jellyfin` install both `jellyfin-server` and `jellyfin-web`, and ensure that both of those packages can be *build* independently (i.e. no cross-dependencies at build time).

backuprepo commented

2025-12-21 19:47:13 +01:00

Author

Owner

@joshuaboniface commented on GitHub (Aug 27, 2020):

One thing that the empty-package format provides, and which I think is worthwhile, though is the ability to have things work differently for both unstable and stable packages.

In the deb form, for unstable packages, there is no version dependencies in the metapackage, thus it will always just grab whatever the "latest" version of the two dependencies is. This is important because the unstable packages get built separately in response to PRs with date-based "version" strings, so they will never match up between web and server. For stable, however, we have a strict (=<vers>) version dependency so that the e.g. 10.6.3 metapackage always pulls in 10.6.3 web and 10.6.3 server. IDK if RPM specs can do it this way, but if so, I would say that's ideal.

The deb equivs-build file is under https://github.com/jellyfin/jellyfin-metapackages for reference; if we do the same thing for RPM, the "empty package" spec will need to live there too, not in the main or web repos.

@joshuaboniface commented on GitHub (Aug 27, 2020): One thing that the empty-package format provides, and which I think is worthwhile, though is the ability to have things work differently for both `unstable` and `stable` packages. In the `deb` form, for `unstable` packages, there is no version dependencies in the metapackage, thus it will always just grab whatever the "latest" version of the two dependencies is. This is important because the `unstable` packages get built separately in response to PRs with date-based "version" strings, so they will never match up between web and server. For stable, however, we have a strict `(=<vers>)` version dependency so that the e.g. 10.6.3 metapackage always pulls in 10.6.3 web and 10.6.3 server. IDK if RPM specs can do it this way, but if so, I would say that's ideal. The `deb` `equivs-build` file is under https://github.com/jellyfin/jellyfin-metapackages for reference; if we do the same thing for RPM, the "empty package" spec will need to live there too, not in the main or web repos.

backuprepo commented

2025-12-21 19:47:15 +01:00

Author

Owner

@brianjmurrell commented on GitHub (Aug 27, 2020):

All of this will require the RPM build of a jellyfin-web package though I suppose. Which is not currently happening.

@brianjmurrell commented on GitHub (Aug 27, 2020): All of this will require the RPM build of a jellyfin-web package though I suppose. Which is not currently happening.

backuprepo commented

2025-12-21 19:47:16 +01:00

Author

Owner

@joshuaboniface commented on GitHub (Aug 27, 2020):

It should be: https://repo.jellyfin.org/releases/server/fedora/stable/

@joshuaboniface commented on GitHub (Aug 27, 2020): It should be: https://repo.jellyfin.org/releases/server/fedora/stable/

backuprepo commented

2025-12-21 19:47:17 +01:00

Author

Owner

@brianjmurrell commented on GitHub (Aug 27, 2020):

Ahh. Is that "repo" something new-ish?

If you put a repo-md repodata/ directory at https://repo.jellyfin.org/releases/server/fedora/stable/ using createrepo you'd have a bona fide repository that people could configure into their yum/dnf package managed systems.

@brianjmurrell commented on GitHub (Aug 27, 2020): Ahh. Is that "repo" something new-ish? If you put a _repo-md_ `repodata/` directory at https://repo.jellyfin.org/releases/server/fedora/stable/ using [`createrepo`](https://linux.die.net/man/8/createrepo) you'd have a bona fide repository that people could configure into their `yum`/`dnf` package managed systems.

backuprepo commented

2025-12-21 19:47:18 +01:00

Author

Owner

@oddstr13 commented on GitHub (Aug 27, 2020):

There is no need for an empty Jellyfin package. The fix is to add a Provides/Obsoletes pair to jellyfin-server.

Obsoletes: jellyfin < 10.6.0
Provides: jellyfin = %{version}-%{release}

This does sound roughly like what we do on the debian side, in addition to the metapackage, so it is probably the right way to go?

521027b2c0/debian/control (L17-L27)

Updating from the old package would probably work with just this, but I don't know if you could install using just apt-get install jellyfin without the metapackage.

@oddstr13 commented on GitHub (Aug 27, 2020): > There is no need for an empty Jellyfin package. The fix is to add a Provides/Obsoletes pair to jellyfin-server. > > Obsoletes: jellyfin < 10.6.0 > Provides: jellyfin = %{version}-%{release} This does sound roughly like what we do on the debian side, in addition to the metapackage, so it is probably the right way to go? https://github.com/jellyfin/jellyfin/blob/521027b2c018a40ecf248cf03e4e6ff4d599e848/debian/control#L17-L27 Updating from the old package would probably work with just this, but I don't know if you could install using just `apt-get install jellyfin` without the metapackage.

backuprepo commented

2025-12-21 19:47:19 +01:00

Author

Owner

@brianjmurrell commented on GitHub (Aug 27, 2020):

This does sound roughly like what we do on the debian side, in addition to the metapackage, so it is probably the right way to go?

IMHO, no. This does not produce the metapackage like the debian side. #4001 is what produces an apples-to-apples RPM build compared to the Debian build. I'm just about to do a build of it and test that my installation (finally) successfully upgrades.

@brianjmurrell commented on GitHub (Aug 27, 2020): > This does sound roughly like what we do on the debian side, in addition to the metapackage, so it is probably the right way to go? IMHO, no. This does not produce the metapackage like the debian side. #4001 is what produces an apples-to-apples RPM build compared to the Debian build. I'm just about to do a build of it and test that my installation (finally) successfully upgrades.

backuprepo commented

2025-12-21 19:47:20 +01:00

Author

Owner

@brianjmurrell commented on GitHub (Aug 27, 2020):

Built and tested to successfully upgrade a 10.5.x jellyfin package.

# dnf upgrade jellyfin
Last metadata expiration check: 0:02:51 ago on Thu 27 Aug 2020 01:50:04 PM EDT.
Dependencies resolved.
================================================================================
 Package         Arch   Version      Repository                            Size
================================================================================
Upgrading:
 jellyfin        x86_64 10.6.3-1.el7 copr:copr.fedorainfracloud.org:brianjmurrell:jellyfin
                                                                          4.4 k
Installing dependencies:
 lttng-ust       x86_64 2.4.1-4.el7  epel                                 176 k
 userspace-rcu   x86_64 0.7.16-1.el7 epel                                  73 k
 jellyfin-server x86_64 10.6.3-1.el7 copr:copr.fedorainfracloud.org:brianjmurrell:jellyfin
                                                                           38 M
 jellyfin-web    noarch 10.6.3-2.el7 copr:copr.fedorainfracloud.org:brianjmurrell:jellyfin
                                                                           30 M

Transaction Summary
================================================================================
Install  4 Packages
Upgrade  1 Package

@brianjmurrell commented on GitHub (Aug 27, 2020): [Built](https://copr.fedorainfracloud.org/coprs/brianjmurrell/jellyfin/build/1637262/) and tested to successfully upgrade a 10.5.x jellyfin package. ``` # dnf upgrade jellyfin Last metadata expiration check: 0:02:51 ago on Thu 27 Aug 2020 01:50:04 PM EDT. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Upgrading: jellyfin x86_64 10.6.3-1.el7 copr:copr.fedorainfracloud.org:brianjmurrell:jellyfin 4.4 k Installing dependencies: lttng-ust x86_64 2.4.1-4.el7 epel 176 k userspace-rcu x86_64 0.7.16-1.el7 epel 73 k jellyfin-server x86_64 10.6.3-1.el7 copr:copr.fedorainfracloud.org:brianjmurrell:jellyfin 38 M jellyfin-web noarch 10.6.3-2.el7 copr:copr.fedorainfracloud.org:brianjmurrell:jellyfin 30 M Transaction Summary ================================================================================ Install 4 Packages Upgrade 1 Package ```

backuprepo commented

2025-12-21 19:47:21 +01:00

Author

Owner

@joshuaboniface commented on GitHub (Aug 27, 2020):

Ahh. Is that "repo" something new-ish?

If you put a repo-md repodata/ directory at https://repo.jellyfin.org/releases/server/fedora/stable/ using createrepo you'd have a bona fide repository that people could configure into their yum/dnf package managed systems.

That's pretty excellent, I had no idea it was that easy!

@joshuaboniface commented on GitHub (Aug 27, 2020): > Ahh. Is that "repo" something new-ish? > > If you put a _repo-md_ `repodata/` directory at https://repo.jellyfin.org/releases/server/fedora/stable/ using [`createrepo`](https://linux.die.net/man/8/createrepo) you'd have a bona fide repository that people could configure into their `yum`/`dnf` package managed systems. That's pretty excellent, I had no idea it was that easy!

backuprepo commented

2025-12-21 19:47:22 +01:00

Author

Owner

@oddstr13 commented on GitHub (Aug 27, 2020):

This does sound roughly like what we do on the debian side, in addition to the metapackage, so it is probably the right way to go?

IMHO, no. This does not produce the metapackage like the debian side. #4001 is what produces an apples-to-apples RPM build compared to the Debian build. I'm just about to do a build of it and test that my installation (finally) successfully upgrades.

We had conflicts on Debian due to order of package install/upgrade iirc – jellyfin-server was attempted installed before jellyfin was upgraded, and file ownership clashed? @joshuaboniface probably knows more about this.

If it works without such measures (the Breaks flag specifically I think), that's probably fine.
But if there exists syntax to explicitly define this incompatibility that should be applied, as the exact behavior may vary between package managers (I know for example apt-get and aptitude differs in some ways here).

@oddstr13 commented on GitHub (Aug 27, 2020): > > This does sound roughly like what we do on the debian side, in addition to the metapackage, so it is probably the right way to go? > > IMHO, no. This does not produce the metapackage like the debian side. #4001 is what produces an apples-to-apples RPM build compared to the Debian build. I'm just about to do a build of it and test that my installation (finally) successfully upgrades. We had conflicts on Debian due to order of package install/upgrade iirc – `jellyfin-server` was attempted installed before `jellyfin` was upgraded, and file ownership clashed? @joshuaboniface probably knows more about this. If it works without such measures (the `Breaks` flag specifically I think), that's probably fine. But if there exists syntax to explicitly define this incompatibility that should be applied, as the exact behavior may vary between package managers (I know for example `apt-get` and `aptitude` differs in some ways here).

backuprepo commented

2025-12-21 19:47:23 +01:00

Author

Owner

@joshuaboniface commented on GitHub (Aug 27, 2020):

Yea there was a weird issue if I didn't put the Breaks: tag in it, IDK if RPM suffers from that issue though.

@joshuaboniface commented on GitHub (Aug 27, 2020): Yea there was a weird issue if I didn't put the Breaks: tag in it, IDK if RPM suffers from that issue though.

backuprepo commented

2025-12-21 19:47:24 +01:00

Author

Owner

@brianjmurrell commented on GitHub (Aug 27, 2020):

It doesn't. It upgraded from 10.5.x even.

@brianjmurrell commented on GitHub (Aug 27, 2020): It doesn't. It upgraded from 10.5.x even.

backuprepo commented

2025-12-21 19:47:25 +01:00

Author

Owner

@brianjmurrell commented on GitHub (Aug 30, 2020):

Hrm. The Fixes: #3701 in #4001 didn't close this.

@brianjmurrell commented on GitHub (Aug 30, 2020): Hrm. The Fixes: #3701 in #4001 didn't close this.

backuprepo commented

2025-12-21 19:47:26 +01:00

Author

Owner

@brianjmurrell commented on GitHub (Aug 30, 2020):

That's pretty excellent, I had no idea it was that easy!

Any chance you can easily set that up @joshuaboniface ? Or would it be easier to set up a webhook in jellyfin-web for COPR? If you recall, the process is:

In your GitHub project, go to Settings / Webhooks.
Click on the Add webhook button.
Fill in the Payload URL field with the url I give you somewhere not so public.
Select application/json as the content type.
Click the Add webhook button

@brianjmurrell commented on GitHub (Aug 30, 2020): > That's pretty excellent, I had no idea it was that easy! Any chance you can easily set that up @joshuaboniface ? Or would it be easier to set up a webhook in jellyfin-web for COPR? If you recall, the process is: 1. In your GitHub project, go to Settings / Webhooks. 1. Click on the Add webhook button. 1. Fill in the Payload URL field with the url I give you somewhere not so public. 1. Select application/json as the content type. 1. Click the Add webhook button

backuprepo referenced this issue

2025-12-22 07:07:07 +01:00

[PR #1949] [MERGED] Update to Dockerfile #8781

Rows
Columns

10.6.0 RPM doesn't update previous versions #1949