Tags corresponding to the release tags of the server/web repos

[mrblumi]

Would it be possible to provide release tags (or even better versioned tarballs) in this repository? That would make it a lot easier for package maintainers of other distros than debian to figure out what commit here belongs to the release tarballs in the server/web repos.

Or am I missing some easy way? I would like to avoid to have to clone this whole repo including all the other repos as submodules in oder to have a consistent state all over server, web, systemd files, config, etc when nearly everything I need is provided as versioned tarball

[joshuaboniface]

I'm not sure I understand the goal of this. This repository is basically a template and set of scripts for generating releases from the main code repos at a particular time. What's in here isn't tied in any way to the actual releases of Jellyfin, and thus, what's in here isn't tagged to particular version of Jellyfin. This is a conscious design decision to keep packaging independent from the code.

[joshuaboniface]

So what I mean is, our goal here is that if something packaging related changes, it changes for everything built going forward. To use the example of the systemd unit, if we update that, then all of a current-stable-release rebuild, the next stable release, the next unstable, etc. would all get that change. Or are you requesting that, after we put out a release, we put a tag in here for historical reasons?

[mrblumi]

I understand that, but that is IMHO exactly the issue.

In Arch Linux for example I want to generate reproducible builds. If I rebuild the exakt same package version a few months later that package could be different than the one from before even if I use the exakt same build script. And I am convinced that Arch won't be the only distribution doing it in similar ways. Imagine somebody would accidently redistribute a package with a changed config or systemd file under the same version number but with a regression in the systemd service file or something like that...

If something in a packaged program is changed at least the package version/build number should be changed, even if it was only the build/packaging process...

Thus something like a versioned release tag or archive would be a huge benefit the moment you put out a new release of the main repositories. Surely we could use a fixed commit hash in the packaging instructions, but having some sort of fixed versioned tag or archive would be much more speaking than just some random hash value

[joshuaboniface]

I can certainly have the packaging repo generate a release (which would include the tarball) as part of the release process. I'm going to add that to our release system, and 10.9.2 (forthcoming) should have it. But I'm a little apprehensive long-term.

The big reason I'm hesitant is our ability to rebuild/repackage in the future. For a bit of context why I want this, in the past we've had more than one occasion where we do a release, but then we find some weird bug in the packaging that forces us to cut a "new" release. One of my goals for splitting out packaging was to decouple these: we could then quickly fix the packaging, retrigger builds, and avoid the major hassle of a proper "code" release. And i would like to preserve that ability, but fixing the packaging to a specific "version" by creating releases fundamentally breaks that (unless we add complex suffixes and such).

That said,.. Arch et al are not built from this repository. What parts are you actively using? IMHO, this repo is for us and our official builds - your Arch etc. builds should have your own management repository with your own copies of the various components needed (e.g. systemd units, config templates, etc.) and pull the upstream code directly.

[joshuaboniface]

A bit more info... how exactly would you pull this. Would it be manual, or are you planning to script it? Are we OK to use arbitrary tag names (I would prefer to use dates rather than tying it to the Jellyfin version for the reasons above), or do you require them to match the official release names?

[mrblumi]

Thanks for clarifying this. I completely understand your point of view. I just didn’t realize that it was not intended for public use (maybe I have missed that)… But If you‘d ask me, (leaving out the fact that the repo is only for your internal use) I‘d prefer a tag matching the jellyfin-server/-web version tag. That would make it easier going back in time and make a match between the server, web and build-tools versions.

I am currently trying to rebuild the Arch package on my own, cause the upstream package is still on 10.8.x and based on the upstream PKGBUILD of Arch I had a bit of a time until i figured out, that the environment file and the systemd unit file disappeared in the 10.9.x repos. What came nearest to something provided by the Jellyfin team were these files in this very repo here to use.

I already thought about just using custom written env and unit files, but I think using these files here and just patching them with my distro specific adjustments would be somehow better because I stay closer to your upstream changes…

[mrblumi]

My first idea was to clone the repo via the build script leaving out the submodules because I already have the server and web tarballs and only pick the files of interest out of the debian conf folder and maybe apply some arch specific patches on them. But all of that would be completely automated inside the PKGBUILD script.

[joshuaboniface]

I am currently trying to rebuild the Arch package on my own, cause the upstream package is still on 10.8.x and based on the upstream PKGBUILD of Arch I had a bit of a time until i figured out, that the environment file and the systemd unit file disappeared in the 10.9.x repos. What came nearest to something provided by the Jellyfin team were these files in this very repo here to use.

Indeed, the files were moved here from the main repos :-)

I already thought about just using custom written env and unit files, but I think using these files here and just patching them with my distro specific adjustments would be somehow better because I stay closer to your upstream changes…

Fair point, and helps ensure consistency between platforms.

My first idea was to clone the repo via the build script leaving out the submodules and only pick the files of interest out of the debian conf folder and maybe apply some arch specific patches on them. But all of that would be completely automated inside the PKGBUILD script.

Makes sense to me.

I‘d prefer a tag matching the jellyfin-server/-web version tag.

OK, I'll do so!

If we do need to update a package and rebuild, we'll have to find a clean way to handle it. My first thought would be to use a dated suffix (-202405170000, -202405180000, etc.) to future rebuilds, but I'm not sure if PKGBUILD can handle that. We could also retag the version, but that sort of defeats the purpose. I'm curious what you think would be ideal here!

[mrblumi]

I'd be perfectly fine with dated suffixes, PKGBUILD files can handle that.

If we do need to update a package and rebuild, we'll have to find a clean way to handle it.

Is that really an issue? If it works now for your rebuilds it will work afterwards as well, would'nt it? You don't have to care about tags or tarballs in that process at all :D

We could also retag the version, but that sort of defeats the purpose. I'm curious what you think would be ideal here!

And yes, retaging the version would somehow lead the whole point absurd :-)

[joshuaboniface]

OK great, dated suffixes are ideal then. So we'd have a tag like v10.9.0-202405170000 in YYYYMMDDHHMM format in this repo, and then if a change + rebuild is needed, an updated date will be tagged.

[joshuaboniface]

Should be active now and going forward.

[mrblumi]

Thanks