[arch-general] conflict on /usr/bin generated by tigervnc?
Hi ! On Today's upgrade: % pacman -Syu :: Synchronizing package databases... ... Packages (9) ... tigervnc-1.11.0-1 ... ... tigervnc-1.11.0-1-x86_64 131.3 MiB 3.51 MiB/s 00:37 [########################################################] 100% (9/9) checking keys in keyring [########################################################] 100% (9/9) checking package integrity [########################################################] 100% (9/9) loading package files [########################################################] 100% (9/9) checking for file conflicts [########################################################] 100% error: failed to commit transaction (conflicting files) tigervnc: /usr/sbin exists in filesystem (owned by filesystem) Errors occurred, no packages were upgraded. Usually that get fixed by using "--overwrite /usr/sbin". But I find it wrong for tigervnc to own "/usr/sbin", so I think in this case tigervnc is not right. Would this be the case, or it's OK for tigervnc to be the owner and then to overwrite? Thanks ! -- Javier
On Wed, 9 Sep 2020 17:41:28 -0600 Javier via arch-general <arch-general@archlinux.org> wrote:
Hi !
On Today's upgrade:
% pacman -Syu :: Synchronizing package databases... ... Packages (9) ... tigervnc-1.11.0-1 ... ... tigervnc-1.11.0-1-x86_64 131.3 MiB 3.51 MiB/s 00:37 [########################################################] 100% (9/9) checking keys in keyring [########################################################] 100% (9/9) checking package integrity [########################################################] 100% (9/9) loading package files [########################################################] 100% (9/9) checking for file conflicts [########################################################] 100% error: failed to commit transaction (conflicting files) tigervnc: /usr/sbin exists in filesystem (owned by filesystem) Errors occurred, no packages were upgraded.
Usually that get fixed by using "--overwrite /usr/sbin". But I find it wrong for tigervnc to own "/usr/sbin", so I think in this case tigervnc is not right. Would this be the case, or it's OK for tigervnc to be the owner and then to overwrite?
Thanks !
NO! DO NOT OVERWRITE! In fact, never overwrite when the file is owned by another package, you'll just create more problems. This is a packaging bug, and this package is currently uninstallable on Arch. Scimmia
On 9/9/20 5:59 PM, Doug Newgard via arch-general wrote:
On Wed, 9 Sep 2020 17:41:28 -0600 Javier via arch-general <arch-general@archlinux.org> wrote:
Hi !
On Today's upgrade:
% pacman -Syu :: Synchronizing package databases... ... Packages (9) ... tigervnc-1.11.0-1 ... ... tigervnc-1.11.0-1-x86_64 131.3 MiB 3.51 MiB/s 00:37 [########################################################] 100% (9/9) checking keys in keyring [########################################################] 100% (9/9) checking package integrity [########################################################] 100% (9/9) loading package files [########################################################] 100% (9/9) checking for file conflicts [########################################################] 100% error: failed to commit transaction (conflicting files) tigervnc: /usr/sbin exists in filesystem (owned by filesystem) Errors occurred, no packages were upgraded.
Usually that get fixed by using "--overwrite /usr/sbin". But I find it wrong for tigervnc to own "/usr/sbin", so I think in this case tigervnc is not right. Would this be the case, or it's OK for tigervnc to be the owner and then to overwrite?
Thanks !
NO! DO NOT OVERWRITE! In fact, never overwrite when the file is owned by another package, you'll just create more problems. This is a packaging bug, and this package is currently uninstallable on Arch.
Scimmia
Understood ! Actually I thought it to be dangerous for sure ! Thanks ! -- Javier
On Wed, Sep 9, 2020, 7:54 PM Javier via arch-general < arch-general@archlinux.org> wrote:
On 9/9/20 5:59 PM, Doug Newgard via arch-general wrote:
On Wed, 9 Sep 2020 17:41:28 -0600 Javier via arch-general <arch-general@archlinux.org> wrote:
Hi !
On Today's upgrade:
% pacman -Syu :: Synchronizing package databases... ... Packages (9) ... tigervnc-1.11.0-1 ... ... tigervnc-1.11.0-1-x86_64 131.3 MiB 3.51 MiB/s 00:37 [########################################################] 100% (9/9) checking keys in keyring
[########################################################] 100%
(9/9) checking package integrity [########################################################] 100% (9/9) loading package files [########################################################] 100% (9/9) checking for file conflicts [########################################################] 100% error: failed to commit transaction (conflicting files) tigervnc: /usr/sbin exists in filesystem (owned by filesystem) Errors occurred, no packages were upgraded.
Usually that get fixed by using "--overwrite /usr/sbin". But I find it wrong for tigervnc to own "/usr/sbin", so I think in this case tigervnc is not right. Would this be the case, or it's OK for tigervnc to be the owner and then to overwrite?
Thanks !
NO! DO NOT OVERWRITE! In fact, never overwrite when the file is owned by another package, you'll just create more problems. This is a packaging bug, and this package is currently uninstallable on Arch.
Scimmia
Understood ! Actually I thought it to be dangerous for sure !
Thanks !
-- Javier
Shouldn't we put something up on the main page about this? Yash
On 9/9/20 8:55 PM, karx via arch-general wrote:
Shouldn't we put something up on the main page about this?
You're right. Let me go put up a news post for this. How does this sound? Title ----------- Don't do stupid things without asking Body ----------- In the event you ever get told a package cannot be installed due to file conflicts with another package, don't try to force it anyway, using non-default options which self-describe as "bypass [safety] checks", that you need to go out of your way to use, especially if you haven't been told to do so. If you actually needed to do manual intervention, we would have published a news post. Just sit tight and wait for a non-broken package to be available for properly installing. Before you pointlessly wreck your system, at least ask on the forum or mailing list first. This message brought to you by the department of the obvious. /s ... The default expectation is you don't use --overwrite unless explicitly told to do so. We won't put up news posts for everything you shouldn't have done. If you somehow do it anyway and post asking for help repairing your system, we will try to help you, but we'll also make sure to lecture you on why it's a bad idea to do it and how you should think twice next time. Do NOT use an emergency repair tool for routine upgrades, only do so when you fully understand why you're doing it, OR the developers of Arch have told you it's the correct approach. If in doubt, ask. And I would like to reiterate: really, really, REALLY, do not use --overwrite unless you know what you're doing or have done as the OP did and asked (and been told to do so). The entire *point* of the option is to declare that your Arch installation is broken and you need to tell pacman that pacman is wrong about your files. By stepping off the beaten path, you incur the possibility of being wrong and making things a lot worse. Do NOT use --overwrite unless you know what you're doing. DO what the original poster did, and ask the experts before proceeding. -- Eli Schwartz Bug Wrangler and Trusted User
Eli,
And I would like to reiterate: really, really, REALLY, do not use --overwrite unless you know what you're doing or have done as the OP did and asked (and been told to do so). The entire *point* of the option is to declare that your Arch installation is broken and you need to tell pacman that pacman is wrong about your files. By stepping off the beaten path, you incur the possibility of being wrong and making things a lot worse.
i wonder if maybe a suitable, upper-cased, warning added to the "--overwrite" section of the man page might be useful? cheers, Greg
On 9/9/20 6:53 PM, Javier wrote:
On 9/9/20 5:59 PM, Doug Newgard via arch-general wrote:
On Wed, 9 Sep 2020 17:41:28 -0600 Javier via arch-general <arch-general@archlinux.org> wrote:
Hi !
On Today's upgrade:
% pacman -Syu :: Synchronizing package databases... ... Packages (9) ... tigervnc-1.11.0-1 ... ... tigervnc-1.11.0-1-x86_64 131.3 MiB 3.51 MiB/s 00:37 [########################################################] 100% (9/9) checking keys in keyring [########################################################] 100% (9/9) checking package integrity [########################################################] 100% (9/9) loading package files [########################################################] 100% (9/9) checking for file conflicts [########################################################] 100% error: failed to commit transaction (conflicting files) tigervnc: /usr/sbin exists in filesystem (owned by filesystem) Errors occurred, no packages were upgraded.
Usually that get fixed by using "--overwrite /usr/sbin". But I find it wrong for tigervnc to own "/usr/sbin", so I think in this case tigervnc is not right. Would this be the case, or it's OK for tigervnc to be the owner and then to overwrite?
Thanks !
NO! DO NOT OVERWRITE! In fact, never overwrite when the file is owned by another package, you'll just create more problems. This is a packaging bug, and this package is currently uninstallable on Arch.
Scimmia
Understood ! Actually I thought it to be dangerous for sure !
Thanks !
BTW, for those waiting for the package fix, it's done, and already replicated on the mirrors. Thanks a lot ! -- Javier
On 10/09/20 5:11 am, Javier via arch-general wrote:
Usually that get fixed by using "--overwrite /usr/sbin". But I find it wrong for tigervnc to own "/usr/sbin", so I think in this case tigervnc is not right. Would this be the case, or it's OK for tigervnc to be the owner and then to overwrite?
Thanks !
With due respect to all developers and package maintainers, I think Arch needs to have policy that maintainer must be using the package they maintain. This will make sure that they dont simply bump the pkgver / pkgrel and release untested package. This bug can create a disaster for someone, if person blindly tries a regular fix to such problems i.e. --overwrite usr/sbin. Their whole system would crash as there will be no symlink to usr/bin and many executables would go missing. And probably will not boot. Amish.
Hi,
With due respect to all developers and package maintainers, I think Arch needs to have policy that maintainer must be using the package they maintain.
This will make sure that they dont simply bump the pkgver / pkgrel and release untested package.
Are you serious?
This bug can create a disaster for someone, if person blindly tries a regular fix to such problems i.e. --overwrite usr/sbin. Their whole system would crash as there will be no symlink to usr/bin and many executables would go missing. And probably will not boot.
You can't blame the developers / package maintainers for users doing stupid things. Regards Bjoern
You can't blame the developers / package maintainers for users doing stupid things.
But you can blame them for releasing a completely broken package. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On 9/9/20 7:41 PM, Javier via arch-general wrote:
error: failed to commit transaction (conflicting files) tigervnc: /usr/sbin exists in filesystem (owned by filesystem) Errors occurred, no packages were upgraded.
Usually that get fixed by using "--overwrite /usr/sbin". But I find it wrong for tigervnc to own "/usr/sbin", so I think in this case tigervnc is not right. Would this be the case, or it's OK for tigervnc to be the owner and then to overwrite?
It is very wrong; the package doesn't even install during the post-build lint checks and should therefore never have been released by the maintainer. In upstream commit https://github.com/TigerVNC/tigervnc/commit/1af1cfdf8709dd1a5574efa19fb4f0e6... a new file got added, and installed to CMAKE_INSTALL_SBINDIR, which defaults to "sbin" and on Arch must be "bin". This failed to happen; it's a bug in the package. Under no circumstances should the filesystem layout be deleted and replaced by this package as it would break everything... https://bugs.archlinux.org/task/67861 is the correct solution. -- Eli Schwartz Bug Wrangler and Trusted User
participants (8)
-
Amish
-
Bjoern Franke
-
Doug Newgard
-
Eli Schwartz
-
Evan McCarthy
-
Greg Minshall
-
Javier
-
karx