Package Details: teamviewer-beta 14.5.5819-1

Git Clone URL: https://aur.archlinux.org/teamviewer-beta.git (read-only)
Package Base: teamviewer-beta
Description: All-In-One Software for Remote Support and Online Meetings
Upstream URL: https://www.teamviewer.com/en-us/download/linux/
Licenses: custom
Conflicts: teamviewer
Provides: teamviewer=14
Submitter: eworm
Maintainer: severach
Last Packager: severach
Votes: 69
Popularity: 0.220961
First Submitted: 2015-11-17 13:22
Last Updated: 2019-09-14 22:48

Latest Comments

1 2 3 4 5 6 ... Next › Last »

CyberShadow commented on 2019-08-25 22:38

It is created again on the next boot, just like it was created the first time on the first boot.

It is created with a different value, no? So, software which depends on the value being consistent on the same machine will be affected.

CyberShadow commented on 2019-08-25 22:37

You're talking Windows Uninstaller talk. Removing a package should restore the system to as close to the clean original as possible.

What makes you say that?

Can you provide some examples of core Arch Linux packages which delete files created by the packaged software during uninstallation?

severach commented on 2019-08-25 22:35

You're talking Windows Uninstaller talk. Removing a package should restore the system to as close to the clean original as possible. All deleted files are TeamViewer files of which the user has no interest. TeamViewer removal leaves a lot of junk files around. I notify the user to they can delete them. I can take the rm off.

You should definitely not be deleting a systemd file just because TeamViewer happens to read it.

"You" the package isn't deleting it. It is completely safe for "You" the user to delete it. It is created again on the next boot, just like it was created the first time on the first boot.

CyberShadow commented on 2019-08-25 18:17

I can delete anything that Teamviewer creates in system folders.

I don't think packages should do anything of the sort, unless the files are created during installation. Uninstalling and reinstalling a package should have no net effect on the system. The only exception are configuration files, as indicated by the backup=(...) array in PKGBUILD files, and when pacman -R is invoked also with -n.

tmpfiles.d allows declaring a list of files and directories created by programs at runtime, including log directories, if that's what you're looking for.

Google TeamViewer Linux "machine-id" to see what it has to do with TeamViewer.

You should definitely not be deleting a systemd file just because TeamViewer happens to read it. It will affect much more than just TeamViewer. If you are going to advise your package's users to delete it, at least add a warning that it may have significant consequences.

I can show you what to clean up to fully remove the package.

I think that's a good idea, but it should probably come with some explanation comments.

severach commented on 2019-08-25 17:58

I was in a hurry to get something that worked. I'll switch to getting home dirs from getent. I can delete anything that Teamviewer creates in system folders. A package can't remove stuff from user dirs. I can show you what to clean up to fully remove the package. Google TeamViewer Linux "machine-id" to see what it has to do with TeamViewer.

CyberShadow commented on 2019-08-25 01:34

Hi, what is with the post_remove hook added in the last "autu" commit? Why is it globbing /home/* instead of using the user database? Why does it remove some things, but only prints commands to remove other things? And how is /etc/machine-id related at all here, considering it's a systemd file and has nothing to do with Teamviewer?

severach commented on 2018-11-11 21:08

A message to enable the server is output if it's not already enabled. Do you want a separate message for only temporarily enabling?

CyberShadow commented on 2018-11-11 17:45

which they probably rarely have to do when most other services all are enabled and started by default

Please name some services for network software (which listens on all interfaces) packaged in Arch Linux that are automatically configured to start upon installation. I'm not aware of any.

(Someone else please correct me if I'm wrong.)

You can do both actions in one command using:

sudo systemctl enable --now teamviewerd

but I dnon't think it's obvious that if someone knows how to run 'yaourt -S', which they do hundreds of times, that they would know how to start a service

IMHO, Arch Linux is not the best Linux distribution for those users.

wjhk23 commented on 2018-11-11 17:38

How about just some output after the install (from the command line at least) which shows the next steps for enabling the server (for those who want it). Although it appears that it's not hard to enable the service, but I dnon't think it's obvious that if someone knows how to run 'yaourt -S', which they do hundreds of times, that they would know how to start a service, which they probably rarely have to do when most other services all are enabled and started by default, without googling (which is easy, but just stating the commands would save time and be easier). For those who came here first expecting a bug than googling how to start (like me), the commands you need are:

sudo systemctl start teamviewerd

sudo systemctl enable teamviewerd

(Someone else please correct me if I'm wrong.)

CyberShadow commented on 2018-10-18 06:00

All my tests show that the client doesn't run without the server running.

If that's true, that must be new - I've definitely used the client before without having to run any server.