Project

General

Profile

Bug #1649

Issues with Emby packaging

Added by cpg almost 5 years ago. Updated almost 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
04/29/2015
Due date:
% Done:

0%


Description

there are a few issues with the packaging of this app:

  • the rpm should just be called Emby.rpm, and probably hosting it in github is also not good. I tried to call it emby-server-3.0.5582.4-amahi.x86_64.rpm to later realize it was originally called Emby-3.0.5582.4-Stable.8.1.noarch.rpm
  • is this rpm binary or noarch?? the "file" command seems to indicate it's binary. the embedded name seems to indicate it's noarch, then the contents has a TON of binary dlls. where do these come from???
  • dependencies are not installing well. this may be an upstream issue, but here it is:
    file /usr/lib64/libmediainfo.so.0.0.0 from install of libmediainfo-0.7.71-1.fc19.x86_64 conflicts with file from package libmediainfo0-0.7.65-297.1.x86_64

can we fix these?

History

#1 Updated by amahimock almost 5 years ago

the rpm should just be called Emby.rpm, and probably hosting it in github is also not good. I tried to call it emby-server-3.0.5582.4-amahi.x86_64.rpm to later realize it was originally called Emby-3.0.5582.4-Stable.8.1.noarch.rpm

The package name should be emby-server-version-releaseType-specVersion-build.noarch.rpm
Where version = the version of the source.
releaseType : indicates if the release was stable/beta/dev (this part can be dropped but it makes it easier to know which release type is currently installed and are available through yum)
specVersion : this number is generated by the opensuse build service each time the spec or one of the files in the solution changes.
buildVersion : this number is generated by the opensuse build service each time the same solution is built.
It doesnt include a distribution name because the package is works with fedora version 19+, centos 6.5+

is this rpm binary or noarch?? the "file" command seems to indicate it's binary. the embedded name seems to indicate it's noarch, then the contents has a TON of binary dlls. where do these come from???

It is no arch due the fact that the arch is determined by mono, the file will run as long as the OS has mono working on it. The dlls are the components of the server , even the plugins get installed as dlls and are not limited by the architecture.

dependencies are not installing well. this may be an upstream issue, but here it is:
file /usr/lib64/libmediainfo.so.0.0.0 from install of libmediainfo-0.7.71-1.fc19.x86_64 conflicts with file from package libmediainfo0-0.7.65-297.1.x86_64

I dont provide libmediainfo and only ask for it is probably an upstream issue.

Also available in: Atom