pacman “exists on filesystem” error












32















I ran sudo pacman -Syu and I got some interesting errors reading:




error: failed to commit transaction (conflicting files)




and a long list of files followed by exists in filesystem. Full output is here: http://ix.io/lLw



It appears that many of these files are not associated with a package when I checked them with pacman -Qo <path-to-file>, but I did not check them all. I had a weak connection when I ran pacman -Syu, but I get the same errors when I updated later: http://ix.io/lLx



What should I do? Should I check all files and delete ones that do not have an associated package? Should I force update (with sudo pacman -S --force <package-name>?)



Update



I tried running sudo pacman -S --force <package-name> and got this:



[my-pc]/home/average-joe$ pacman -Qo /usr/lib/python3.5/site-packages/PyYAML-3.11-py3.5.egg-info
error: No package owns /usr/lib/python3.5/site-packages/PyYAML-3.11-py3.5.egg-info


It looks like pacman -S --force <package does not overwrite directories that contain files. From the man:




Using --force will not allow overwriting a directory with a file or installing packages with conflicting files and directories.




Should I just delete the conflicting directories? (they do not have associated packages)










share|improve this question


















  • 5





    why do you have conflicting files in the first place? when using a package manager, try not to tap on its toes (e.g. by installing software in places the package manager rightfully thinks is theirs; if you must install things manually, install to /usr/local/ rather than /usr/)

    – umläute
    Nov 2 '15 at 12:37






  • 1





    @umläute I am not exactly sure where the conflicting files came from, but I suspect they are related to my installation of docker-compose which I installed using sudo pip install -U docker-compose==1.5.0rc3 on this page. Perhaps sudo pip install conflicts with pacman?

    – modulitos
    Nov 3 '15 at 7:47






  • 1





    @umläute Getting wrong -S updates (partial installs, etc) will let you that scenario. Case of me --force worked all times.

    – erm3nda
    May 23 '17 at 17:15
















32















I ran sudo pacman -Syu and I got some interesting errors reading:




error: failed to commit transaction (conflicting files)




and a long list of files followed by exists in filesystem. Full output is here: http://ix.io/lLw



It appears that many of these files are not associated with a package when I checked them with pacman -Qo <path-to-file>, but I did not check them all. I had a weak connection when I ran pacman -Syu, but I get the same errors when I updated later: http://ix.io/lLx



What should I do? Should I check all files and delete ones that do not have an associated package? Should I force update (with sudo pacman -S --force <package-name>?)



Update



I tried running sudo pacman -S --force <package-name> and got this:



[my-pc]/home/average-joe$ pacman -Qo /usr/lib/python3.5/site-packages/PyYAML-3.11-py3.5.egg-info
error: No package owns /usr/lib/python3.5/site-packages/PyYAML-3.11-py3.5.egg-info


It looks like pacman -S --force <package does not overwrite directories that contain files. From the man:




Using --force will not allow overwriting a directory with a file or installing packages with conflicting files and directories.




Should I just delete the conflicting directories? (they do not have associated packages)










share|improve this question


















  • 5





    why do you have conflicting files in the first place? when using a package manager, try not to tap on its toes (e.g. by installing software in places the package manager rightfully thinks is theirs; if you must install things manually, install to /usr/local/ rather than /usr/)

    – umläute
    Nov 2 '15 at 12:37






  • 1





    @umläute I am not exactly sure where the conflicting files came from, but I suspect they are related to my installation of docker-compose which I installed using sudo pip install -U docker-compose==1.5.0rc3 on this page. Perhaps sudo pip install conflicts with pacman?

    – modulitos
    Nov 3 '15 at 7:47






  • 1





    @umläute Getting wrong -S updates (partial installs, etc) will let you that scenario. Case of me --force worked all times.

    – erm3nda
    May 23 '17 at 17:15














32












32








32


8






I ran sudo pacman -Syu and I got some interesting errors reading:




error: failed to commit transaction (conflicting files)




and a long list of files followed by exists in filesystem. Full output is here: http://ix.io/lLw



It appears that many of these files are not associated with a package when I checked them with pacman -Qo <path-to-file>, but I did not check them all. I had a weak connection when I ran pacman -Syu, but I get the same errors when I updated later: http://ix.io/lLx



What should I do? Should I check all files and delete ones that do not have an associated package? Should I force update (with sudo pacman -S --force <package-name>?)



Update



I tried running sudo pacman -S --force <package-name> and got this:



[my-pc]/home/average-joe$ pacman -Qo /usr/lib/python3.5/site-packages/PyYAML-3.11-py3.5.egg-info
error: No package owns /usr/lib/python3.5/site-packages/PyYAML-3.11-py3.5.egg-info


It looks like pacman -S --force <package does not overwrite directories that contain files. From the man:




Using --force will not allow overwriting a directory with a file or installing packages with conflicting files and directories.




Should I just delete the conflicting directories? (they do not have associated packages)










share|improve this question














I ran sudo pacman -Syu and I got some interesting errors reading:




error: failed to commit transaction (conflicting files)




and a long list of files followed by exists in filesystem. Full output is here: http://ix.io/lLw



It appears that many of these files are not associated with a package when I checked them with pacman -Qo <path-to-file>, but I did not check them all. I had a weak connection when I ran pacman -Syu, but I get the same errors when I updated later: http://ix.io/lLx



What should I do? Should I check all files and delete ones that do not have an associated package? Should I force update (with sudo pacman -S --force <package-name>?)



Update



I tried running sudo pacman -S --force <package-name> and got this:



[my-pc]/home/average-joe$ pacman -Qo /usr/lib/python3.5/site-packages/PyYAML-3.11-py3.5.egg-info
error: No package owns /usr/lib/python3.5/site-packages/PyYAML-3.11-py3.5.egg-info


It looks like pacman -S --force <package does not overwrite directories that contain files. From the man:




Using --force will not allow overwriting a directory with a file or installing packages with conflicting files and directories.




Should I just delete the conflicting directories? (they do not have associated packages)







arch-linux pacman






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 2 '15 at 11:31









modulitosmodulitos

1,17261939




1,17261939








  • 5





    why do you have conflicting files in the first place? when using a package manager, try not to tap on its toes (e.g. by installing software in places the package manager rightfully thinks is theirs; if you must install things manually, install to /usr/local/ rather than /usr/)

    – umläute
    Nov 2 '15 at 12:37






  • 1





    @umläute I am not exactly sure where the conflicting files came from, but I suspect they are related to my installation of docker-compose which I installed using sudo pip install -U docker-compose==1.5.0rc3 on this page. Perhaps sudo pip install conflicts with pacman?

    – modulitos
    Nov 3 '15 at 7:47






  • 1





    @umläute Getting wrong -S updates (partial installs, etc) will let you that scenario. Case of me --force worked all times.

    – erm3nda
    May 23 '17 at 17:15














  • 5





    why do you have conflicting files in the first place? when using a package manager, try not to tap on its toes (e.g. by installing software in places the package manager rightfully thinks is theirs; if you must install things manually, install to /usr/local/ rather than /usr/)

    – umläute
    Nov 2 '15 at 12:37






  • 1





    @umläute I am not exactly sure where the conflicting files came from, but I suspect they are related to my installation of docker-compose which I installed using sudo pip install -U docker-compose==1.5.0rc3 on this page. Perhaps sudo pip install conflicts with pacman?

    – modulitos
    Nov 3 '15 at 7:47






  • 1





    @umläute Getting wrong -S updates (partial installs, etc) will let you that scenario. Case of me --force worked all times.

    – erm3nda
    May 23 '17 at 17:15








5




5





why do you have conflicting files in the first place? when using a package manager, try not to tap on its toes (e.g. by installing software in places the package manager rightfully thinks is theirs; if you must install things manually, install to /usr/local/ rather than /usr/)

– umläute
Nov 2 '15 at 12:37





why do you have conflicting files in the first place? when using a package manager, try not to tap on its toes (e.g. by installing software in places the package manager rightfully thinks is theirs; if you must install things manually, install to /usr/local/ rather than /usr/)

– umläute
Nov 2 '15 at 12:37




1




1





@umläute I am not exactly sure where the conflicting files came from, but I suspect they are related to my installation of docker-compose which I installed using sudo pip install -U docker-compose==1.5.0rc3 on this page. Perhaps sudo pip install conflicts with pacman?

– modulitos
Nov 3 '15 at 7:47





@umläute I am not exactly sure where the conflicting files came from, but I suspect they are related to my installation of docker-compose which I installed using sudo pip install -U docker-compose==1.5.0rc3 on this page. Perhaps sudo pip install conflicts with pacman?

– modulitos
Nov 3 '15 at 7:47




1




1





@umläute Getting wrong -S updates (partial installs, etc) will let you that scenario. Case of me --force worked all times.

– erm3nda
May 23 '17 at 17:15





@umläute Getting wrong -S updates (partial installs, etc) will let you that scenario. Case of me --force worked all times.

– erm3nda
May 23 '17 at 17:15










4 Answers
4






active

oldest

votes


















22














Ok, it looks like running sudo pacman -S --force <package-name> works, but it doesn't resolve conflicting directories. In such cases, running sudo rm -rf on the conflicting directories, followed by sudo pacman -S --force <package-name> works.



Now my pacman -Syu resolves well.






share|improve this answer





















  • 3





    --force is deprecated; use --overwrite instead.

    – Ankit Balyan
    Jun 14 '18 at 8:37






  • 5





    --force is working for me but --overwrite is not

    – Infernion
    Jun 18 '18 at 13:19






  • 1





    sudo pacman -Syu --force worked for me, but overwrite wasn't recognized.

    – spydon
    Jul 2 '18 at 8:03



















18














tl;dr: Uninstall the conflicting application before running pacman.



pacman (and other package managers) keep an index of packages and files that they manage (pacman --query --list). Some files, such as configuration, will be marked as modifiable and will not be overwritten during upgrade (except in special circumstances, where the package manager will typically move away the old file before creating the new one). Other files will be marked as unmodifiable. If another application changes those files in any way without updating the index accordingly there's no way for the package manager to know what to do with those files during an upgrade.



Many applications installed using the standard ./configure && make && sudo make install pattern can be uninstalled using sudo make uninstall. If you have installed the application in some other way you might have to something else to uninstall it. In general it can be a good idea to keep a copy of installation files somewhere (for example ~/install) to be able to reliably uninstall them in such cases. Just removing the conflicting files will probably leave other files lying around, which could conceivably cause other problems.



When installing software with other package managers there are ways to isolate those from the system files. This is an established best practice for example during software development, where you really want to keep versions consistent and avoid conflicts with other software. Examples include:





  • Python Virtualenv (example; in use)

  • Ruby Version Manager






share|improve this answer





















  • 1





    See my comment to @umlaute above. I think the conflict was from a sudo pip install command. Perhaps I should avoid using pip with sudo?

    – modulitos
    Nov 3 '15 at 7:48



















1














I was installing packages that I usually install with pip via pacman because of this. But some packages arent found in pacman repos. I think we should avoid installing pip with sudo privilegies and istead:



pip install pillow --user


--user flag makes pip install packages in your home directory instead, which doesn't require any special privileges.https://stackoverflow.com/questions/42988977/what-is-the-purpose-pip-install-user






share|improve this answer































    0














    TLDR;




    1. Get a list of the offending files (copy and paste pacman's output into a file).

    2. Use awk to strip out everything but the file paths into a new list.

    3. Use while to move the offending files out of the way, based on the list.

    4. Run sudo pacman -Syu again.


      edited to add TLDR and fix typos




    Although I'm pretty sure I haven't been doing anything stupid, I've had this problem maybe every other time I've tried to update since I've been using Manjaro; three or four times within two months. Point being, this fixes it.




    Get a list of your files.



    When the update fails in your terminal window, you get this:



    error: failed to commit transaction (conflicting files)
    evilfile: /usr/bin/evilfile exists in filesystem
    libx000: /usr/lib/libx000.so.f.u.loser exists in filesystem
    accountsservice: /usr/share/locale/ru/LC_MESSAGES/accounts-service.mo.yu.dnt.evn.spk.russian exists in filesystem


    ... and a lot more.




    • Copy the output from the terminal, and put it in a file. I used nano, and named mine "files," as in ~/work/files.



    • Strip extraneous info:



      cat files | awk '{print $2}' >> ~/work/files2



      This takes the second "word" from each line and prints it to files2.




    Deal with the files




    • You could delete them, move them, or rename them.


    • If something breaks, it's easiest to fix if we break it by moving it instead of deleting or renaming it:
      mkdir ~/work/oldfiles
      while read -r file; do sudo mv -- "$file" ~/work/oldfiles/$file; done < files2


    • If you really want to delete them, which there is no reason to do (DANGER DANGER): while read -r file; do sudo rm -- "$file"; done < files2



    Updating





    • To get --overwrite to work, which we need to do to get pacman to realize the package isn't broken, you need the following syntax:



      sudo pacman -S package_name --overwrite /location/of/thing




      • In my case: sudo pacman -S libidn2 --overwrite /usr/lib/libidn2.so.0

      • Following the example: sudo pacman -S libx000 --overwrite /usr/lib/libx000.so.f.u.loser



    • I had a cute problem where if I deleted the libidn2.so.0 symlink, nothing worked, and when I put it back, I got the "exists on filesystem" error. The above, with --overwrite, is all that worked for me.



    • Finally:



      sudo pacman -Syu








    share|improve this answer

























      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "106"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: false,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f240252%2fpacman-exists-on-filesystem-error%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      4 Answers
      4






      active

      oldest

      votes








      4 Answers
      4






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      22














      Ok, it looks like running sudo pacman -S --force <package-name> works, but it doesn't resolve conflicting directories. In such cases, running sudo rm -rf on the conflicting directories, followed by sudo pacman -S --force <package-name> works.



      Now my pacman -Syu resolves well.






      share|improve this answer





















      • 3





        --force is deprecated; use --overwrite instead.

        – Ankit Balyan
        Jun 14 '18 at 8:37






      • 5





        --force is working for me but --overwrite is not

        – Infernion
        Jun 18 '18 at 13:19






      • 1





        sudo pacman -Syu --force worked for me, but overwrite wasn't recognized.

        – spydon
        Jul 2 '18 at 8:03
















      22














      Ok, it looks like running sudo pacman -S --force <package-name> works, but it doesn't resolve conflicting directories. In such cases, running sudo rm -rf on the conflicting directories, followed by sudo pacman -S --force <package-name> works.



      Now my pacman -Syu resolves well.






      share|improve this answer





















      • 3





        --force is deprecated; use --overwrite instead.

        – Ankit Balyan
        Jun 14 '18 at 8:37






      • 5





        --force is working for me but --overwrite is not

        – Infernion
        Jun 18 '18 at 13:19






      • 1





        sudo pacman -Syu --force worked for me, but overwrite wasn't recognized.

        – spydon
        Jul 2 '18 at 8:03














      22












      22








      22







      Ok, it looks like running sudo pacman -S --force <package-name> works, but it doesn't resolve conflicting directories. In such cases, running sudo rm -rf on the conflicting directories, followed by sudo pacman -S --force <package-name> works.



      Now my pacman -Syu resolves well.






      share|improve this answer















      Ok, it looks like running sudo pacman -S --force <package-name> works, but it doesn't resolve conflicting directories. In such cases, running sudo rm -rf on the conflicting directories, followed by sudo pacman -S --force <package-name> works.



      Now my pacman -Syu resolves well.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Jun 20 '18 at 6:25

























      answered Nov 2 '15 at 11:43









      modulitosmodulitos

      1,17261939




      1,17261939








      • 3





        --force is deprecated; use --overwrite instead.

        – Ankit Balyan
        Jun 14 '18 at 8:37






      • 5





        --force is working for me but --overwrite is not

        – Infernion
        Jun 18 '18 at 13:19






      • 1





        sudo pacman -Syu --force worked for me, but overwrite wasn't recognized.

        – spydon
        Jul 2 '18 at 8:03














      • 3





        --force is deprecated; use --overwrite instead.

        – Ankit Balyan
        Jun 14 '18 at 8:37






      • 5





        --force is working for me but --overwrite is not

        – Infernion
        Jun 18 '18 at 13:19






      • 1





        sudo pacman -Syu --force worked for me, but overwrite wasn't recognized.

        – spydon
        Jul 2 '18 at 8:03








      3




      3





      --force is deprecated; use --overwrite instead.

      – Ankit Balyan
      Jun 14 '18 at 8:37





      --force is deprecated; use --overwrite instead.

      – Ankit Balyan
      Jun 14 '18 at 8:37




      5




      5





      --force is working for me but --overwrite is not

      – Infernion
      Jun 18 '18 at 13:19





      --force is working for me but --overwrite is not

      – Infernion
      Jun 18 '18 at 13:19




      1




      1





      sudo pacman -Syu --force worked for me, but overwrite wasn't recognized.

      – spydon
      Jul 2 '18 at 8:03





      sudo pacman -Syu --force worked for me, but overwrite wasn't recognized.

      – spydon
      Jul 2 '18 at 8:03













      18














      tl;dr: Uninstall the conflicting application before running pacman.



      pacman (and other package managers) keep an index of packages and files that they manage (pacman --query --list). Some files, such as configuration, will be marked as modifiable and will not be overwritten during upgrade (except in special circumstances, where the package manager will typically move away the old file before creating the new one). Other files will be marked as unmodifiable. If another application changes those files in any way without updating the index accordingly there's no way for the package manager to know what to do with those files during an upgrade.



      Many applications installed using the standard ./configure && make && sudo make install pattern can be uninstalled using sudo make uninstall. If you have installed the application in some other way you might have to something else to uninstall it. In general it can be a good idea to keep a copy of installation files somewhere (for example ~/install) to be able to reliably uninstall them in such cases. Just removing the conflicting files will probably leave other files lying around, which could conceivably cause other problems.



      When installing software with other package managers there are ways to isolate those from the system files. This is an established best practice for example during software development, where you really want to keep versions consistent and avoid conflicts with other software. Examples include:





      • Python Virtualenv (example; in use)

      • Ruby Version Manager






      share|improve this answer





















      • 1





        See my comment to @umlaute above. I think the conflict was from a sudo pip install command. Perhaps I should avoid using pip with sudo?

        – modulitos
        Nov 3 '15 at 7:48
















      18














      tl;dr: Uninstall the conflicting application before running pacman.



      pacman (and other package managers) keep an index of packages and files that they manage (pacman --query --list). Some files, such as configuration, will be marked as modifiable and will not be overwritten during upgrade (except in special circumstances, where the package manager will typically move away the old file before creating the new one). Other files will be marked as unmodifiable. If another application changes those files in any way without updating the index accordingly there's no way for the package manager to know what to do with those files during an upgrade.



      Many applications installed using the standard ./configure && make && sudo make install pattern can be uninstalled using sudo make uninstall. If you have installed the application in some other way you might have to something else to uninstall it. In general it can be a good idea to keep a copy of installation files somewhere (for example ~/install) to be able to reliably uninstall them in such cases. Just removing the conflicting files will probably leave other files lying around, which could conceivably cause other problems.



      When installing software with other package managers there are ways to isolate those from the system files. This is an established best practice for example during software development, where you really want to keep versions consistent and avoid conflicts with other software. Examples include:





      • Python Virtualenv (example; in use)

      • Ruby Version Manager






      share|improve this answer





















      • 1





        See my comment to @umlaute above. I think the conflict was from a sudo pip install command. Perhaps I should avoid using pip with sudo?

        – modulitos
        Nov 3 '15 at 7:48














      18












      18








      18







      tl;dr: Uninstall the conflicting application before running pacman.



      pacman (and other package managers) keep an index of packages and files that they manage (pacman --query --list). Some files, such as configuration, will be marked as modifiable and will not be overwritten during upgrade (except in special circumstances, where the package manager will typically move away the old file before creating the new one). Other files will be marked as unmodifiable. If another application changes those files in any way without updating the index accordingly there's no way for the package manager to know what to do with those files during an upgrade.



      Many applications installed using the standard ./configure && make && sudo make install pattern can be uninstalled using sudo make uninstall. If you have installed the application in some other way you might have to something else to uninstall it. In general it can be a good idea to keep a copy of installation files somewhere (for example ~/install) to be able to reliably uninstall them in such cases. Just removing the conflicting files will probably leave other files lying around, which could conceivably cause other problems.



      When installing software with other package managers there are ways to isolate those from the system files. This is an established best practice for example during software development, where you really want to keep versions consistent and avoid conflicts with other software. Examples include:





      • Python Virtualenv (example; in use)

      • Ruby Version Manager






      share|improve this answer















      tl;dr: Uninstall the conflicting application before running pacman.



      pacman (and other package managers) keep an index of packages and files that they manage (pacman --query --list). Some files, such as configuration, will be marked as modifiable and will not be overwritten during upgrade (except in special circumstances, where the package manager will typically move away the old file before creating the new one). Other files will be marked as unmodifiable. If another application changes those files in any way without updating the index accordingly there's no way for the package manager to know what to do with those files during an upgrade.



      Many applications installed using the standard ./configure && make && sudo make install pattern can be uninstalled using sudo make uninstall. If you have installed the application in some other way you might have to something else to uninstall it. In general it can be a good idea to keep a copy of installation files somewhere (for example ~/install) to be able to reliably uninstall them in such cases. Just removing the conflicting files will probably leave other files lying around, which could conceivably cause other problems.



      When installing software with other package managers there are ways to isolate those from the system files. This is an established best practice for example during software development, where you really want to keep versions consistent and avoid conflicts with other software. Examples include:





      • Python Virtualenv (example; in use)

      • Ruby Version Manager







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited Nov 3 '15 at 8:16

























      answered Nov 2 '15 at 12:57









      l0b0l0b0

      28.4k19119248




      28.4k19119248








      • 1





        See my comment to @umlaute above. I think the conflict was from a sudo pip install command. Perhaps I should avoid using pip with sudo?

        – modulitos
        Nov 3 '15 at 7:48














      • 1





        See my comment to @umlaute above. I think the conflict was from a sudo pip install command. Perhaps I should avoid using pip with sudo?

        – modulitos
        Nov 3 '15 at 7:48








      1




      1





      See my comment to @umlaute above. I think the conflict was from a sudo pip install command. Perhaps I should avoid using pip with sudo?

      – modulitos
      Nov 3 '15 at 7:48





      See my comment to @umlaute above. I think the conflict was from a sudo pip install command. Perhaps I should avoid using pip with sudo?

      – modulitos
      Nov 3 '15 at 7:48











      1














      I was installing packages that I usually install with pip via pacman because of this. But some packages arent found in pacman repos. I think we should avoid installing pip with sudo privilegies and istead:



      pip install pillow --user


      --user flag makes pip install packages in your home directory instead, which doesn't require any special privileges.https://stackoverflow.com/questions/42988977/what-is-the-purpose-pip-install-user






      share|improve this answer




























        1














        I was installing packages that I usually install with pip via pacman because of this. But some packages arent found in pacman repos. I think we should avoid installing pip with sudo privilegies and istead:



        pip install pillow --user


        --user flag makes pip install packages in your home directory instead, which doesn't require any special privileges.https://stackoverflow.com/questions/42988977/what-is-the-purpose-pip-install-user






        share|improve this answer


























          1












          1








          1







          I was installing packages that I usually install with pip via pacman because of this. But some packages arent found in pacman repos. I think we should avoid installing pip with sudo privilegies and istead:



          pip install pillow --user


          --user flag makes pip install packages in your home directory instead, which doesn't require any special privileges.https://stackoverflow.com/questions/42988977/what-is-the-purpose-pip-install-user






          share|improve this answer













          I was installing packages that I usually install with pip via pacman because of this. But some packages arent found in pacman repos. I think we should avoid installing pip with sudo privilegies and istead:



          pip install pillow --user


          --user flag makes pip install packages in your home directory instead, which doesn't require any special privileges.https://stackoverflow.com/questions/42988977/what-is-the-purpose-pip-install-user







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jul 25 '18 at 16:48









          lava-lavalava-lava

          1112




          1112























              0














              TLDR;




              1. Get a list of the offending files (copy and paste pacman's output into a file).

              2. Use awk to strip out everything but the file paths into a new list.

              3. Use while to move the offending files out of the way, based on the list.

              4. Run sudo pacman -Syu again.


                edited to add TLDR and fix typos




              Although I'm pretty sure I haven't been doing anything stupid, I've had this problem maybe every other time I've tried to update since I've been using Manjaro; three or four times within two months. Point being, this fixes it.




              Get a list of your files.



              When the update fails in your terminal window, you get this:



              error: failed to commit transaction (conflicting files)
              evilfile: /usr/bin/evilfile exists in filesystem
              libx000: /usr/lib/libx000.so.f.u.loser exists in filesystem
              accountsservice: /usr/share/locale/ru/LC_MESSAGES/accounts-service.mo.yu.dnt.evn.spk.russian exists in filesystem


              ... and a lot more.




              • Copy the output from the terminal, and put it in a file. I used nano, and named mine "files," as in ~/work/files.



              • Strip extraneous info:



                cat files | awk '{print $2}' >> ~/work/files2



                This takes the second "word" from each line and prints it to files2.




              Deal with the files




              • You could delete them, move them, or rename them.


              • If something breaks, it's easiest to fix if we break it by moving it instead of deleting or renaming it:
                mkdir ~/work/oldfiles
                while read -r file; do sudo mv -- "$file" ~/work/oldfiles/$file; done < files2


              • If you really want to delete them, which there is no reason to do (DANGER DANGER): while read -r file; do sudo rm -- "$file"; done < files2



              Updating





              • To get --overwrite to work, which we need to do to get pacman to realize the package isn't broken, you need the following syntax:



                sudo pacman -S package_name --overwrite /location/of/thing




                • In my case: sudo pacman -S libidn2 --overwrite /usr/lib/libidn2.so.0

                • Following the example: sudo pacman -S libx000 --overwrite /usr/lib/libx000.so.f.u.loser



              • I had a cute problem where if I deleted the libidn2.so.0 symlink, nothing worked, and when I put it back, I got the "exists on filesystem" error. The above, with --overwrite, is all that worked for me.



              • Finally:



                sudo pacman -Syu








              share|improve this answer






























                0














                TLDR;




                1. Get a list of the offending files (copy and paste pacman's output into a file).

                2. Use awk to strip out everything but the file paths into a new list.

                3. Use while to move the offending files out of the way, based on the list.

                4. Run sudo pacman -Syu again.


                  edited to add TLDR and fix typos




                Although I'm pretty sure I haven't been doing anything stupid, I've had this problem maybe every other time I've tried to update since I've been using Manjaro; three or four times within two months. Point being, this fixes it.




                Get a list of your files.



                When the update fails in your terminal window, you get this:



                error: failed to commit transaction (conflicting files)
                evilfile: /usr/bin/evilfile exists in filesystem
                libx000: /usr/lib/libx000.so.f.u.loser exists in filesystem
                accountsservice: /usr/share/locale/ru/LC_MESSAGES/accounts-service.mo.yu.dnt.evn.spk.russian exists in filesystem


                ... and a lot more.




                • Copy the output from the terminal, and put it in a file. I used nano, and named mine "files," as in ~/work/files.



                • Strip extraneous info:



                  cat files | awk '{print $2}' >> ~/work/files2



                  This takes the second "word" from each line and prints it to files2.




                Deal with the files




                • You could delete them, move them, or rename them.


                • If something breaks, it's easiest to fix if we break it by moving it instead of deleting or renaming it:
                  mkdir ~/work/oldfiles
                  while read -r file; do sudo mv -- "$file" ~/work/oldfiles/$file; done < files2


                • If you really want to delete them, which there is no reason to do (DANGER DANGER): while read -r file; do sudo rm -- "$file"; done < files2



                Updating





                • To get --overwrite to work, which we need to do to get pacman to realize the package isn't broken, you need the following syntax:



                  sudo pacman -S package_name --overwrite /location/of/thing




                  • In my case: sudo pacman -S libidn2 --overwrite /usr/lib/libidn2.so.0

                  • Following the example: sudo pacman -S libx000 --overwrite /usr/lib/libx000.so.f.u.loser



                • I had a cute problem where if I deleted the libidn2.so.0 symlink, nothing worked, and when I put it back, I got the "exists on filesystem" error. The above, with --overwrite, is all that worked for me.



                • Finally:



                  sudo pacman -Syu








                share|improve this answer




























                  0












                  0








                  0







                  TLDR;




                  1. Get a list of the offending files (copy and paste pacman's output into a file).

                  2. Use awk to strip out everything but the file paths into a new list.

                  3. Use while to move the offending files out of the way, based on the list.

                  4. Run sudo pacman -Syu again.


                    edited to add TLDR and fix typos




                  Although I'm pretty sure I haven't been doing anything stupid, I've had this problem maybe every other time I've tried to update since I've been using Manjaro; three or four times within two months. Point being, this fixes it.




                  Get a list of your files.



                  When the update fails in your terminal window, you get this:



                  error: failed to commit transaction (conflicting files)
                  evilfile: /usr/bin/evilfile exists in filesystem
                  libx000: /usr/lib/libx000.so.f.u.loser exists in filesystem
                  accountsservice: /usr/share/locale/ru/LC_MESSAGES/accounts-service.mo.yu.dnt.evn.spk.russian exists in filesystem


                  ... and a lot more.




                  • Copy the output from the terminal, and put it in a file. I used nano, and named mine "files," as in ~/work/files.



                  • Strip extraneous info:



                    cat files | awk '{print $2}' >> ~/work/files2



                    This takes the second "word" from each line and prints it to files2.




                  Deal with the files




                  • You could delete them, move them, or rename them.


                  • If something breaks, it's easiest to fix if we break it by moving it instead of deleting or renaming it:
                    mkdir ~/work/oldfiles
                    while read -r file; do sudo mv -- "$file" ~/work/oldfiles/$file; done < files2


                  • If you really want to delete them, which there is no reason to do (DANGER DANGER): while read -r file; do sudo rm -- "$file"; done < files2



                  Updating





                  • To get --overwrite to work, which we need to do to get pacman to realize the package isn't broken, you need the following syntax:



                    sudo pacman -S package_name --overwrite /location/of/thing




                    • In my case: sudo pacman -S libidn2 --overwrite /usr/lib/libidn2.so.0

                    • Following the example: sudo pacman -S libx000 --overwrite /usr/lib/libx000.so.f.u.loser



                  • I had a cute problem where if I deleted the libidn2.so.0 symlink, nothing worked, and when I put it back, I got the "exists on filesystem" error. The above, with --overwrite, is all that worked for me.



                  • Finally:



                    sudo pacman -Syu








                  share|improve this answer















                  TLDR;




                  1. Get a list of the offending files (copy and paste pacman's output into a file).

                  2. Use awk to strip out everything but the file paths into a new list.

                  3. Use while to move the offending files out of the way, based on the list.

                  4. Run sudo pacman -Syu again.


                    edited to add TLDR and fix typos




                  Although I'm pretty sure I haven't been doing anything stupid, I've had this problem maybe every other time I've tried to update since I've been using Manjaro; three or four times within two months. Point being, this fixes it.




                  Get a list of your files.



                  When the update fails in your terminal window, you get this:



                  error: failed to commit transaction (conflicting files)
                  evilfile: /usr/bin/evilfile exists in filesystem
                  libx000: /usr/lib/libx000.so.f.u.loser exists in filesystem
                  accountsservice: /usr/share/locale/ru/LC_MESSAGES/accounts-service.mo.yu.dnt.evn.spk.russian exists in filesystem


                  ... and a lot more.




                  • Copy the output from the terminal, and put it in a file. I used nano, and named mine "files," as in ~/work/files.



                  • Strip extraneous info:



                    cat files | awk '{print $2}' >> ~/work/files2



                    This takes the second "word" from each line and prints it to files2.




                  Deal with the files




                  • You could delete them, move them, or rename them.


                  • If something breaks, it's easiest to fix if we break it by moving it instead of deleting or renaming it:
                    mkdir ~/work/oldfiles
                    while read -r file; do sudo mv -- "$file" ~/work/oldfiles/$file; done < files2


                  • If you really want to delete them, which there is no reason to do (DANGER DANGER): while read -r file; do sudo rm -- "$file"; done < files2



                  Updating





                  • To get --overwrite to work, which we need to do to get pacman to realize the package isn't broken, you need the following syntax:



                    sudo pacman -S package_name --overwrite /location/of/thing




                    • In my case: sudo pacman -S libidn2 --overwrite /usr/lib/libidn2.so.0

                    • Following the example: sudo pacman -S libx000 --overwrite /usr/lib/libx000.so.f.u.loser



                  • I had a cute problem where if I deleted the libidn2.so.0 symlink, nothing worked, and when I put it back, I got the "exists on filesystem" error. The above, with --overwrite, is all that worked for me.



                  • Finally:



                    sudo pacman -Syu









                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited 10 mins ago

























                  answered 20 mins ago









                  Fin HirschoffFin Hirschoff

                  12




                  12






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Unix & Linux Stack Exchange!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f240252%2fpacman-exists-on-filesystem-error%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      CARDNET

                      Boot-repair Failure: Unable to locate package grub-common:i386

                      濃尾地震