Linux repos vs new installer packages

[doonze 30]

Luke, 

   Didn't what to keep hijacking that other thread so I started this one. I'm trying to get my head around the differences. You said the mono repo packages are still being updated, but are not as up to date overall as the new installer? Can someone expand on that a little?

 

And can the new installer version download and update itself? Or do you have to go download a new .deb every time there is an update?

 

What's the advantages over the new installer version as apposed to what's in the repos? And is there a reason we can't get the repo version and new installer version to be the same?

 

And I've noticed issues when I've switched back and forth from the installer version vs. the repo version. Hosed my DB one time, and lost all my settings another. Are there any instruction to prevent these issues?

 

Thanks, I'm just trying to see if it worth it for me to drop the repo version in favor of the new installer. I can't be the only one. 

 

Thanks Emby team for all you do! 

Edited January 2, 2018 by doonze

[Luke 42078]

The newer packages are built with .net core instead of mono, and the .net core runtime is smaller, faster, more efficient, etc. Additionally the ffmpeg setup is all self contained so you never have to mess with that.

 

The repository packages are still being updated with new versions of emby server but we are not touching the packages themselves. This allows everyone to keep using what they're using, while using the website to direct all new users towards our new packages. It's not really intended to be a user preference, eventually the old way will be deprecated. Thanks.

[Volfan6415 19]

I assume then at some point the repository packages will switch to .net core and those running .net core will be able to update via repository?

 

 

Sent from my iPhone using Tapatalk

[Luke 42078]

We're not sure yet. If we think the risk of problems is high then it could be a while before we do that, if we ever do. We can still have the current repositories build against mono and continue to push out mono-based packages.

[doonze 30]

Ok, I'm understanding now. I like the idea of getting away from mono. But my one last question is: Is the server installed from the new server package able to self-update?

 

If it can keep itself up to date then I have no need for the repo. I use the repo for easy updating only. If it can't, then I'll have to stick with the repo version. 

[Luke 42078]

It will notify you when updates are available.

[doonze 30]

You guys have forgotten more than I know about linux packages, but how hard would it be to have it self-update to the latest version when one is available? It would be an option of course, for those that don't like to take updates till they are ready. I know with linux it's more of a challenge, but my couchpotato does it. Not that they update that very often, but it does self-update. 

[dcrdev 255]

You guys have forgotten more than I know about linux packages, but how hard would it be to have it self-update to the latest version when one is available? It would be an option of course, for those that don't like to take updates till they are ready. I know with linux it's more of a challenge, but my couchpotato does it. Not that they update that very often, but it does self-update.

Well then if Emby didn't want to break Linux packaging, would need to take command of your package manager and you definitely do not want that.

 

The easiest solution would be for them to put the packages on a web server and run the relevant (2 minute commands) - "createrepo ." for yum/dnf and "dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz" for debian/ubuntu. All it requires is a server to host web server, requires no additional dependencies etc...

 

I hate the new manual process too, I've written a small bash script that retrieves the latest release rpm from GitHub using cURL/sed, if it has the stable tag - the rpm is then stored in my existing repo directory and createrepo is run after; I have this on a daily cron. Bit of a faff, but end result is I get automatic updates.

[doonze 30]

Well then if Emby didn't want to break Linux packaging, would need to take command of your package manager and you definitely do not want that.

 

The easiest solution would be for them to put the packages on a web server and run the relevant (2 minute commands) - "createrepo ." for yum/dnf and "dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz" for debian/ubuntu. All it requires is a server to host web server, requires no additional dependencies etc...

 

I hate the new manual process too, I've written a small bash script that retrieves the latest release rpm from GitHub using cURL/sed, if it has the stable tag - the rpm is then stored in my existing repo directory and createrepo is run after; I have this on a daily cron. Bit of a faff, but end result is I get automatic updates.

 

Is the github version the same as the new "installer" version? If so I'd be interested in that script. Can you share it?

 

I've tried to figure out a way to write a bash script to wget it from the installer page, but since the path and version number change I'm not sure how to handle that. I'd have to know what the new release was before downloading it. I do that manually now, since my server is headless, but I can't get my mind around the logic that could figure out the new path/file when it changes. 

 

 @@Luke autoupdater.... hint hint.......

Edited January 6, 2018 by doonze

[dcrdev 255]

No friggin auto-updater! It goes against how Linux packaging is supposed to work - it'll actually break package management.

 

Web Hosting + Package + Repository + Package Signing = Simple

 

@@doonze one script, that I should have almost certainly written in Python:

#!/bin/bash
arch="x86_64"
package="rpm"
embyReleases=$(curl -s  https://api.github.com/repos/MediaBrowser/Emby/releases)

poorMansJson () {

  local firstRelease=$(echo "$embyReleases" \
  | awk '$0 ~ "\"prerelease\": false" {print NR}' | head -n 1)

  local lastPackage=$(echo "$embyReleases" \
  | tail --lines="+$firstRelease" \
  | awk '$0 ~ "'$arch.$package'" {print NR}' | head -n 1) 

  local lastPackage=$((lastPackage + firstRelease - 1))
  embyVersion=$(echo "$embyReleases" | awk "FNR==$lastPackage" \
  | sed -E 's/.*"([^"]+)".*/\1/')

  downloadUrl=$(echo "$embyReleases" \
  | awk "/download/ && /$embyVersion/" \
  | sed -E 's/.*"([^"]+)".*/\1/')

}

poorMansJson &&
curl -L "$downloadUrl" > "$embyVersion" &&
"Release Downloaded"

Edited January 6, 2018 by dcrdev

[tdiguy 99]

I am curious on this, if emby did decide to do the repo thing again could they simply distribute the pre build packages in such a manner ( ie the .deb files )? Rather than a partial build that may or may not have issues with dependencies that are not always handled gracefully by the system.

I do like the idea of using a repo, but these pre-built packages are really foolproof for installing compared to what it used to be like installing emby.

[Luke 42078]

foolproof 

 

this is the most important thing of all.

[dcrdev 255]

Yes they absolutely could just add the existing packages to a repository without going the modular approach.

 

That's what I'm doing -

^ That script above - is run on a daily cron

• It downloads the package to /path/to/repo and this is served via Apache at https://repo.domain.com/el7/x86_64
• Seperately I have an inotify script watching that directory for changes - when there is one it runs "createrepo /path/to/repo" and that's it.

There are no issues around this - I simply run "yum update" and that's that.

 

I'd say having it in a repository is more foolproof than a manual installation.