[arch-general] libxfont: removing fontsproto breaks dependency 'fontsproto>=2.1.3'
All, Attempting to upgrade tonight I am met with a fontsproto breaks dependency 'fontsproto>=2.1.3' error and pacman quits. Is this a repo-sync issue or is this a bug? :: Synchronizing package databases... core 127.8 KiB 367K/s 00:00 [########################################] 100% extra 1594.6 KiB 3.31M/s 00:00 [########################################] 100% community 4.1 MiB 2.91M/s 00:01 [########################################] 100% :: Starting full system upgrade... :: Replace compositeproto with extra/xorgproto? [Y/n] :: Replace damageproto with extra/xorgproto? [Y/n] :: Replace fixesproto with extra/xorgproto? [Y/n] :: Replace fontsproto with extra/xorgproto? [Y/n] :: Replace inputproto with extra/xorgproto? [Y/n] :: Replace kbproto with extra/xorgproto? [Y/n] :: Replace randrproto with extra/xorgproto? [Y/n] :: Replace recordproto with extra/xorgproto? [Y/n] :: Replace renderproto with extra/xorgproto? [Y/n] :: Replace videoproto with extra/xorgproto? [Y/n] :: Replace xextproto with extra/xorgproto? [Y/n] :: Replace xf86vidmodeproto with extra/xorgproto? [Y/n] :: Replace xineramaproto with extra/xorgproto? [Y/n] :: Replace xproto with extra/xorgproto? [Y/n] resolving dependencies... looking for conflicting packages... error: failed to prepare transaction (could not satisfy dependencies) :: libxfont: removing fontsproto breaks dependency 'fontsproto>=2.1.3' Let me know if I need to open a ticket, if not I'll just wait and see if something is posted on archlinux.org or the mirrors fix this problem... -- David C. Rankin, J.D.,P.E.
On Fri, 9 Feb 2018 20:53:01 -0600 "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:
All,
Attempting to upgrade tonight I am met with a fontsproto breaks dependency 'fontsproto>=2.1.3' error and pacman quits. Is this a repo-sync issue or is this a bug?
It's neither. Why do you still have libxfont installed?
On 02/09/2018 09:17 PM, Doug Newgard via arch-general wrote:
On Fri, 9 Feb 2018 20:53:01 -0600 "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:
All,
Attempting to upgrade tonight I am met with a fontsproto breaks dependency 'fontsproto>=2.1.3' error and pacman quits. Is this a repo-sync issue or is this a bug?
It's neither. Why do you still have libxfont installed?
Damned if I know?? Name : libxfont Version : 1.5.3-1 Description : X11 font rasterisation library Architecture : x86_64 URL : https://xorg.freedesktop.org/ Licenses : custom Groups : None Provides : None Depends On : freetype2 libfontenc xproto fontsproto>=2.1.3 Optional Deps : None Required By : None Optional For : None Conflicts With : None Replaces : None Installed Size : 300.00 KiB Packager : Laurent Carlier <lordheavym@gmail.com> Build Date : Thu 19 Oct 2017 10:56:59 PM CDT Install Date : Sat 21 Oct 2017 08:57:48 AM CDT Install Reason : Installed as a dependency for another package Install Script : No Validated By : Signature Should I not have it? -- David C. Rankin, J.D.,P.E.
On Fri, 9 Feb 2018 21:46:43 -0600 "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:
On 02/09/2018 09:17 PM, Doug Newgard via arch-general wrote:
On Fri, 9 Feb 2018 20:53:01 -0600 "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:
All,
Attempting to upgrade tonight I am met with a fontsproto breaks dependency 'fontsproto>=2.1.3' error and pacman quits. Is this a repo-sync issue or is this a bug?
It's neither. Why do you still have libxfont installed?
Damned if I know??
Name : libxfont Version : 1.5.3-1 Description : X11 font rasterisation library Architecture : x86_64 URL : https://xorg.freedesktop.org/ Licenses : custom Groups : None Provides : None Depends On : freetype2 libfontenc xproto fontsproto>=2.1.3 Optional Deps : None Required By : None Optional For : None Conflicts With : None Replaces : None Installed Size : 300.00 KiB Packager : Laurent Carlier <lordheavym@gmail.com> Build Date : Thu 19 Oct 2017 10:56:59 PM CDT Install Date : Sat 21 Oct 2017 08:57:48 AM CDT Install Reason : Installed as a dependency for another package Install Script : No Validated By : Signature
Should I not have it?
It no longer exists in the repos. You have nothing depending on it. It's causing you problems. The solution seems obvious.
On 02/09/2018 09:49 PM, Doug Newgard via arch-general wrote:
It no longer exists in the repos. You have nothing depending on it. It's causing you problems. The solution seems obvious.
Obvious solution applied, (pacman -R libxfont), update proceeded normally, gremlins? Sorry for the noise... -- David C. Rankin, J.D.,P.E.
On Fri, 9 Feb 2018 21:54:10 -0600 "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:
On 02/09/2018 09:49 PM, Doug Newgard via arch-general wrote:
It no longer exists in the repos. You have nothing depending on it. It's causing you problems. The solution seems obvious.
Obvious solution applied, (pacman -R libxfont), update proceeded normally, gremlins?
Sorry for the noise...
Not gremlins, just an old package that never got cleaned out. Pacman doesn't do this automatically.
On 02/09/2018 09:55 PM, Doug Newgard via arch-general wrote:
On Fri, 9 Feb 2018 21:54:10 -0600 "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:
On 02/09/2018 09:49 PM, Doug Newgard via arch-general wrote:
It no longer exists in the repos. You have nothing depending on it. It's causing you problems. The solution seems obvious.
Obvious solution applied, (pacman -R libxfont), update proceeded normally, gremlins?
Sorry for the noise...
Not gremlins, just an old package that never got cleaned out. Pacman doesn't do this automatically.
Thanks Doug, I clued into that fact when I looked closer at: Groups : None Provides : None Depends On : freetype2 libfontenc xproto fontsproto>=2.1.3 Optional Deps : None Required By : None Optional For : None Conflicts With : None Replaces : None It was first installed as a dependency when the system was first installed in 2016. So I'm not sure what the culprit was. I'm always hesitant to just start pacman -R'ing packages, but now I know how to check if the obvious solution is warranted... -- David C. Rankin, J.D.,P.E.
2018-02-10 1:55 GMT-02:00 Doug Newgard via arch-general < arch-general@archlinux.org>:
Not gremlins, just an old package that never got cleaned out. Pacman doesn't do this automatically.
Sorry to hijack this trhead, but so that pacman does not clean automagically this kind of packages. What is the recommended way to keep a clean box?
On 14 February 2018 at 19:35, Eduardo Machado via arch-general < arch-general@archlinux.org> wrote:
2018-02-10 1:55 GMT-02:00 Doug Newgard via arch-general < arch-general@archlinux.org>:
Not gremlins, just an old package that never got cleaned out. Pacman doesn't do this automatically.
Sorry to hijack this trhead,
but so that pacman does not clean automagically this kind of packages. What is the recommended way to keep a clean box?
pacman -Rs $(pacman -Qqdt)
Maarten de Vries ALIANDIKA: # pacman -Rs $(pacman -Qqdt) Unfortunately this will break my system. It's trying to remove git for one thing, which is definitely something I need. Not to mention that I installed git explicitly, so pacman definitely shouldn't be removing it. I can see a whole lot of other explicitly installed packages as well as packages that are installed as build dependencies that would also be removed using this method, which is unacceptable at least on my system. On the initial topic of this thread, there has to be a cleaner way to be sure that packages like libxfont get removed in an automated way because they are no longer needed, rather than my upgrade causing an error because a package that is no longer in the repository breaks the upgrade instead of just being removed. It also doesn't help that there wasn't even so much as a news post on the subject before this unclean update was introduced. And when people are called stupid and worse for reporting and reopening a bug report because their upgrade process was broken and no news post was announced, I don't care how many times the bug report was reopened, users, even experienced users like myself, find this very off-putting. It does more to drive good people away than it does to help anyone. TBH I'm actually glad someone brought this to the public list and that the link to the closed bug report was added, so that we can see the true nature of the beast here. Users are never supposed to be the enemy, but even experienced power users who have contributed and don't post much to the list except to try to help when possible now feel we are being treated like last weeks garbage due to the handling of this dirty package upgrade, the lack of a news post and subsequent insults hurled at the community for reporting the bug, and yes, it is a bug, even if the best resolution is to post news. At the very least, a better explanation is in order, rather than insulting the intelligence of users and outright name calling because someone disagrees with the concept of a dirty upgrade being a bug. Imetumwa kutoka habari zetu
On Wed, Feb 14, 2018 at 03:32:35PM -0500, Kyle wrote:
Maarten de Vries ALIANDIKA: # pacman -Rs $(pacman -Qqdt)
Unfortunately this will break my system. It's trying to remove git for one thing, which is definitely something I need. Not to mention that I installed git explicitly, so pacman definitely shouldn't be removing it. I can see a whole lot of other explicitly installed packages as well as packages that are installed as build dependencies that would also be removed using this method, which is unacceptable at least on my system.
On the initial topic of this thread, there has to be a cleaner way to be sure that packages like libxfont get removed in an automated way because they are no longer needed, rather than my upgrade causing an error because a package that is no longer in the repository breaks the upgrade instead of just being removed. It also doesn't help that there wasn't even so much as a news post on the subject before this unclean update was introduced. And when people are called stupid and worse for reporting and reopening a bug report because their upgrade process was broken and no news post was announced, I don't care how many times the bug report was reopened, users, even experienced users like myself, find this very off-putting. It does more to drive good people away than it does to help anyone. TBH I'm actually glad someone brought this to the public list and that the link to the closed bug report was added, so that we can see the true nature of the beast here. Users are never supposed to be the enemy, but even experienced power users who have contributed and don't post much to the list except to try to help when possible now feel we are being treated like last weeks garbage due to the handling of this dirty package upgrade, the lack of a news post and subsequent insults hurled at the community for reporting the bug, and yes, it is a bug, even if the best resolution is to post news. At the very least, a better explanation is in order, rather than insulting the intelligence of users and outright name calling because someone disagrees with the concept of a dirty upgrade being a bug. Imetumwa kutoka habari zetu
Use a pacman hook to notify yourself of new orphans after a transaction if you don't want to check periodically. Packages dropped in the remote repositories will become orphans on your local system. Then you can manually decide what you want to do with an orphaned package. Either mark it as explicitly installed or remove it. See: https://wiki.archlinux.org/index.php?title=Pacman&curid=1577&diff=510810&old...
On 14 February 2018 at 21:32, Kyle <kyle@free2.ml> wrote:
Maarten de Vries ALIANDIKA: # pacman -Rs $(pacman -Qqdt)
Unfortunately this will break my system. It's trying to remove git for one thing, which is definitely something I need. Not to mention that I installed git explicitly, so pacman definitely shouldn't be removing it. I can see a whole lot of other explicitly installed packages as well as packages that are installed as build dependencies that would also be removed using this method, which is unacceptable at least on my system.
This should not be the case. The -d flag to pacman -Q restricts the output to packages installed as dependency. The -t option restricts it to packages that are no longer needed by any other package. If that command removes a package, pacman thinks it's an unneeded dependency. So my guess is that either you had a typo, or the packages are currently indeed in pacman's local database as installed as dependency. Check the output of pacman -Qi for the packages that you think are marked as explicitly installed (in particular "Install Reason" near the bottom). Now, considering that this should work (if it does not there are other problems), I think occasionally doing this manually is fine. Heck, if you must, put it on a cronjob. But it will probably break your system from time to time because it may turn out you were actually using packages that happened to be installed as a dependency. That on it's own is enough reason for me not to make pacman do it automatically. Regardless of who is lazy and who is stupid or not. P.S. The -s flag to pacman -R is just there so you get rid of packages that will be unneeded dependencies after the removal in one go. I actually kinda like leaving it off an running the command multiple times to see how often I have to run it before everything is gone. Everybody needs a hobby.
On Wed, Feb 14, 2018 at 15:32:35 -0500, Kyle wrote:
I can see a whole lot of other explicitly installed packages as well as packages that are installed as build dependencies that would also be removed using this method, which is unacceptable at least on my system.
If you don't want packages to be removed by the given command, install them explicitly. Or better, write a meta-package that keeps them in as a dependency (so you also know *why* they are installed, and makes system housekeeping easier in general). Something like: pkgname='foobar-depends' pkgver=2018.02.14 pkgrel=1 arch=(any) pkgdesc='Dependencies for fooing bars from baz' package() { depends=(git meson libpng12 sl) } This way you know that e.g. libpng12 is installed on your system because you occasionally like to foo some bars from baz. Best, Tinu
Thanks for all your thoughts. it will help me try something to better maintain my boxes.
participants (7)
-
David C. Rankin
-
Doug Newgard
-
Eduardo Machado
-
Kyle
-
Maarten de Vries
-
Tinu Weber
-
Wes Barnett