Solved ScreenConnect agent on Fedora fails rpm install
-
@JaredBusch said in ScreenConnect agent on Fedora fails rpm install:
You have no idea what you are talking about.
I didn't say it would work. I only said standalone RPM installs can be problematic in a yum/dnf managed system. But cheers on being an @hole, well done
-
@EddieJennings said in ScreenConnect agent on Fedora fails rpm install:
Why not?
Because if you ever start using a proper repo for further updates to the package, you'll have to clean it up manually first. The RPM and all of its dependencies. Manually. That's a nice way to mess up a well configured system, in the long run.
yum localinstall (the "local" part is optional as of RHEL6, for the nitpicky types here) places the package in the yum db, so if you make a newer one available in a repo, updates will happen naturally. Removing it and it's dependencies will also be as simple as yum remove.
-
@dyasny said in ScreenConnect agent on Fedora fails rpm install:
@EddieJennings said in ScreenConnect agent on Fedora fails rpm install:
Why not?
Because if you ever start using a proper repo for further updates to the package, you'll have to clean it up manually first. The RPM and all of its dependencies. Manually. That's a nice way to mess up a well configured system, in the long run.
yum localinstall (the "local" part is optional as of RHEL6, for the nitpicky types here) places the package in the yum db, so if you make a newer one available in a repo, updates will happen naturally. Removing it and it's dependencies will also be as simple as yum remove.
And this just reinforces that you have no idea what you are talking about.
If you had any clue, you would realize that this is a on the fly create RPM to install the client software specific to the installation it was created from.
There is no way possible for this to ever be involved in a repository in any fashion whatsoever.
-
@JaredBusch said in ScreenConnect agent on Fedora fails rpm install:
And this just reinforces that you have no idea what you are talking about.
If you had any clue, you would realize that this is a on the fly create RPM to install the client software specific to the installation it was created from.
There is no way possible for this to ever be involved in a repository in any fashion whatsoever.
What I pointed at is the best practice for ANY RPM file. In this particular case you may be right, but if you deal with RPM based systems as much as I do, you'd do well to drop the attitude, you might actually learn something.
-
@dyasny said in ScreenConnect agent on Fedora fails rpm install:
@EddieJennings said in ScreenConnect agent on Fedora fails rpm install:
Why not?
Because if you ever start using a proper repo for further updates to the package, you'll have to clean it up manually first. The RPM and all of its dependencies. Manually. That's a nice way to mess up a well configured system, in the long run.
yum localinstall (the "local" part is optional as of RHEL6, for the nitpicky types here) places the package in the yum db, so if you make a newer one available in a repo, updates will happen naturally. Removing it and it's dependencies will also be as simple as yum remove.
I see your meaning now.
Installing an RPM directly is never a good idea.
I read this as never install RPMs directly, which wouldn't make sense, because for some things, such as ScreenConnect, create RPMs on demand; thus, they'd never be in a repo -- As Jared mention.
-
@EddieJennings said in ScreenConnect agent on Fedora fails rpm install:
@dyasny said in ScreenConnect agent on Fedora fails rpm install:
@EddieJennings said in ScreenConnect agent on Fedora fails rpm install:
Why not?
Because if you ever start using a proper repo for further updates to the package, you'll have to clean it up manually first. The RPM and all of its dependencies. Manually. That's a nice way to mess up a well configured system, in the long run.
yum localinstall (the "local" part is optional as of RHEL6, for the nitpicky types here) places the package in the yum db, so if you make a newer one available in a repo, updates will happen naturally. Removing it and it's dependencies will also be as simple as yum remove.
I see your meaning now.
Installing an RPM directly is never a good idea.
I read this as never install RPMs directly, which wouldn't make sense, because for some things, such as ScreenConnect, create RPMs on demand; thus, they'd never be in a repo -- As Jared mention.
His point is that you can use yum or dnf instead of rpm directly.
All those tools should be pulling their information from the same database.
If an rpm requires dependencies that aren't currently installed but available in a repository on the system, it's much more convenient to install it using yum or dnf rather than rpm.
-
@EddieJennings said in ScreenConnect agent on Fedora fails rpm install:
I read this as never install RPMs directly, which wouldn't make sense, because for some things, such as ScreenConnect, create RPMs on demand; thus, they'd never be in a repo -- As Jared mention.
You read it correctly. My point is, best practice is to always use yum, even for standalone RPMs, because $reasons (and if there are deps, yum will automatically resolve them). Even if the best practice is not applicable and you have a completely standalone package there, it's best to stick to best practices, just like you put on a seatbelt even when you drive 20 yards to your mailbox and back.
-
@dyasny yum/dnf does not magically resolve dependencies.
The RPM has to have them noted.
-
@JaredBusch said in ScreenConnect agent on Fedora fails rpm install:
@dyasny yum/dnf does not magically resolve dependencies.
The RPM has to have them noted.
Yup, only the rpm command will try to install and fail, while the yum command will resolve the deps.
-
@dyasny said in ScreenConnect agent on Fedora fails rpm install:
@JaredBusch said in ScreenConnect agent on Fedora fails rpm install:
@dyasny yum/dnf does not magically resolve dependencies.
The RPM has to have them noted.
Yup, only the rpm command will try to install and fail, while the yum command will resolve the deps.
Only if the deps are defined in the RPM package.
-
YUM or DNF is the better way to go, but yeah, if the RPM doesn't have any deps, they won't do anything special compared to just installing with the RPM command. I would agree, a better practice to use them, but remember that they might not have any dependencies to check against.
-
@JaredBusch said in ScreenConnect agent on Fedora fails rpm install:
Only if the deps are defined in the RPM package.
You really cannot distinguish between an RPM packaging format and the rpm command?
-
@dyasny said in ScreenConnect agent on Fedora fails rpm install:
@JaredBusch said in ScreenConnect agent on Fedora fails rpm install:
Only if the deps are defined in the RPM package.
You really cannot distinguish between an RPM packaging format and the rpm command?
Wha? I think @JaredBusch can distinguish between the two just fine.
-
@travisdh1 said in ScreenConnect agent on Fedora fails rpm install:
Wha? I think @JaredBusch can distinguish between the two just fine.
He's skipping from installing packages using the rpm command to the specifics of formatting the dependency chain in an RPM package declaration. Two very different things right there
-
@JaredBusch said in ScreenConnect agent on Fedora fails rpm install:
rpm -U ConnectWiseControl.ClientSetup.rpm
ConnectWise Control version 19.0.23234.7027 resolved the failure to update. but they neglected to remove the old screenconnect version as the new install is named connectwisecontrol
