[SOLVED] Edit pacman database to remove deps from a package

igormalov · 2018-02-13 20:24:04

Hi,

When I installed gtk3 I ran `pacman` with `--assume-installed dconf,rest,desktop-file-utils,colord` because I don't want those packages on my system. Now when I run `yaourt -Syua` to update packages I see this in the output:

error: missing 'dconf' dependency for 'gtk3'
error: missing 'desktop-file-utils' dependency for 'gtk3'
error: missing 'colord' dependency for 'gtk3'
error: missing 'rest' dependency for 'gtk3'
error: missing 'libcups' dependency for 'gtk3'

How can I edit the pacman database to remove those deps from the gtk3 metadata? Building a custom gtk3 package takes a lot of time so I would prefer to edit the package metadata instead.

Last edited by igormalov (2018-02-13 20:28:08)

igormalov · 2018-02-13 20:27:48

I found the package metadata at /var/lib/pacman/local/gtk3-3.22.26+161+g60750b3ffd-1/desc. After removing the packages from that file there are no longer error messages in yaourt output.

eschwartz · 2018-02-13 20:37:26

Editing the package metadata does not remove the actual code in gtk3 which relies on those packages. Also this message does not come from yaourt, so why do you keep on referring to yaourt???

You need to build gtk3 so it does not try to use those dependencies, rather than simply uninstall the package.

igormalov · 2018-02-14 00:15:33

The code is in pacman (src/pacman/database.c) however I use `yaourt -Syua` to update my system and that is where the missing deps output shows. `pacman -Syu` does not have that output.

gtk3 runs fine without those packages. Therefore editing the desc file of the package is a good solution. I've marked this post as solved.

Last edited by igormalov (2018-02-14 00:30:42)

Trilby · 2018-02-14 00:24:15

If your last post is correct, there seems to be a far far easier solution (with many additional benefits) here that you don't seem to be considering.

eschwartz · 2018-02-14 01:12:11

igormalov wrote:

The code is in pacman (src/pacman/database.c) however I use `yaourt -Syua` to update my system and that is where the missing deps output shows. `pacman -Syu` does not have that output.

So, the error message comes from pacman, but it only shows when you use yaourt? You're either lying, or delusional, or a resident of a parallel universe, or someone who really should have shown more than a carefully curated, useless extract of the whole output of the command.

Most likely the last.

gtk3 runs fine without those packages. Therefore editing the desc file of the package is a good solution. I've marked this post as solved.

gtk3-print-backends requires most of those, see https://bugs.archlinux.org/task/50513 for why we split that package out in the first place, and https://bugs.archlinux.org/task/56445 for why we added it back again.
desktop-file-utils was added as a dependency in gtk3 3.20.3-4, but if you really thought it was a good idea to remove it despite it being a rather important 162.00 KiB dependency for essentially any sort of xdg or desktop handling at all, why didn't you try filing a bugreport?

Or else, creating a dummy package to mask it. This workaround of yours *will* break the next time gtk3 itself is updated.

...

Regardless, you now have an invisibly broken print dialog, so I hope you don't try creating help threads or bugreports after trying and failing to print things.
You also have at a minimum a broken XDG desktop database that doesn't show what is actually available, so I hope that never becomes relevant to you as you won't have any indication of why it is working.

Last edited by eschwartz (2018-02-14 01:35:57)

Allan · 2018-02-14 01:17:59

Eschwartz wrote:

So, the error message comes from pacman, but it only shows when you use yaourt? You're either lying, or delusional, or a resident of a parallel universe, or someone who really should have shown more than a carefully curated, useless extract of the whole output of the command.

or... yaourt is probably running "pacman -Dk" at the end.

eschwartz · 2018-02-14 01:29:18

I figured it was option 4, but it never hurts to be thorough!

Also, yes yaourt runs pacman -Dk unless you set NO_TESTDB=1 in yaourtrc(5). Interestingly, yaourt actually came to *save* users from borked databases... which promptly caused an issue when some yaourt user actually *wanted* a borked database.

Last edited by eschwartz (2018-02-14 01:32:09)

Trilby · 2018-02-14 01:50:00

Eschwartz wrote:

I figured it was option 4, but it never hurts to be thorough!

Claims of residency not-withstanding, I still suspect the existence of the requirements for option 3, and strictly speaking - given that none of the options are mutually exclusive - there has been no evidence presented that would rule out options 1 and 2.

igormalov · 2018-02-14 02:32:25

Just wanted to say that it's been awesome with pacman and yaourt the past 10 years. But I only use 2 gui apps -- firefox and termite -- and don't need all the optional packages that the firefox, pulseaudio, ffmpeg, and gtk3 package maintainers force like gtk2, rest, webrtc-audio-processing, rtkit, polkit, dconf, libssh, libavc1394, libiec61883, or libraw1394. Maintaining a local ffmpeg package isn't that much work but I don't want to custom compile firefox, pulseaudio, gtk3, and other packages when the optional deps can be excluded on install with `--assume-installed`. Like why do you need gtk2 for firefox or libssh for ffmpeg? lol At least gtk2 support is dropped in firefox 59 so that dep is going away.

Last edited by igormalov (2018-02-14 02:37:12)

igormalov · 2018-02-14 03:06:08

Eschwartz wrote:

why didn't you try filing a bugreport?

Reports have already been submitted to remove those deps from gtk3
* https://bugs.archlinux.org/task/36745
* https://bugs.archlinux.org/task/31679
* https://bugs.archlinux.org/task/50513

and also to remove gtk2 from firefox
* https://bugs.archlinux.org/task/56347
* https://bugs.archlinux.org/task/53479
* https://bugs.archlinux.org/task/54031
* https://bugs.archlinux.org/task/49123
* https://bugs.archlinux.org/task/47398

Anyways the maintainers of those packages are known for being difficult with requests to remove deps. I know they're doing this on their own time and they maintain a lot of packages (therefore don't have much time for testing) but there are many people willing to help out. I wish they would allow some other people to contribute.

eschwartz · 2018-02-14 03:11:16

igormalov wrote:

Just wanted to say that it's been awesome with pacman and yaourt the past 10 years. But I only use 2 gui apps -- firefox and termite -- and don't need all the optional packages that the firefox, pulseaudio, ffmpeg, and gtk3 package maintainers force like gtk2, rest, webrtc-audio-processing, rtkit, polkit, dconf, libssh, libavc1394, libiec61883, or libraw1394. Maintaining a local ffmpeg package isn't that much work but I don't want to custom compile firefox, pulseaudio, gtk3, and other packages when the optional deps can be excluded on install with `--assume-installed`. Like why do you need gtk2 for firefox or libssh for ffmpeg? lol At least gtk2 support is dropped in firefox 59 so that dep is going away.

ffmpeg is built with sftp support, which means there is a shared library dependency on libssh. If it is worth it to you to compile ffmpeg without sftp support in order to save 500KB of installed space for libssh.so, go right ahead. But if you use --assume-installed for libssh then any application linked to libavformat.so.57 will fail with a rather fatal error. Which is why it is *stupid* to just --assume-installed whenever you feel you don't want something... why do you think dependencies exist anyway, just to be annoying?

As for Firefox, that bug means absolutely nothing. You cannot build with --enable-default-toolkit=cairo-gtk2 anyway, and they are just removing dead code from the codebase.
The only reason Firefox depends on gtk2 at all is because of the plugin container for Flash which that Mozilla bug is not removing, but see https://bugs.archlinux.org/task/47398

EDIT:

igormalov wrote:

Anyways the maintainers of those packages are known for being difficult with requests to remove deps. I know they're doing this on their own time and they maintain a lot of packages (therefore don't have much time for testing) but there are many people willing to help out. I wish they would allow some other people to contribute.

I assure you this gets tested, no one is being difficult here.

If by "allow some other people to contribute" you mean "give commit access to every random yahoo who thinks they know better", then no, this will never happen. You can contribute by filing a bug, which someone has done, and the fact that the developers disagree with you is not an indictment nor does it mean they are somehow clueless or don't have time to test and realize that you're somehow magically right.

Last edited by eschwartz (2018-02-14 03:16:57)

Trilby · 2018-02-14 03:27:44

Eschwartz wrote:

nor does it mean they are somehow clueless or don't have time to test and realize that you're somehow magically right.

Nor does it mean the OP is magically wrong either.

Don't get me wrong, the OPs manner of presenting their point of view is on the opposite end of the map from productive, but choices on build flags that impact dependencies are - in large part - subjective. The developers are certainly not clueless, but it is perfectly fair for a user to say that their tastes differ greatly from the devs/packagers. I frequently find myself in such a position: I feel a lot of our packages are including a lot more bells and whisles by default than they used to.

But, of course, the response to this is for those of us with more minimalist preferences to rebuild the packages ourselves.

igormalov · 2018-02-14 03:32:23

Sorry you are getting mad. Thank you for all the work you do.

I don't want access to the repository and don't expect anyone to change the packages. I was hoping to find a simple method to remove those error messages and I did. I like being able to customize my system.

The reason why I don't want to have those unnecessary background processes running is because they pollute logs, slow apps, and take up battery power.

eschwartz · 2018-02-14 03:46:37

Trilby wrote:

Eschwartz wrote:
nor does it mean they are somehow clueless or don't have time to test and realize that you're somehow magically right.
Nor does it mean the OP is magically wrong either.
Don't get me wrong, the OPs manner of presenting their point of view is on the opposite end of the map from productive, but choices on build flags that impact dependencies are - in large part - subjective. The developers are certainly not clueless, but it is perfectly fair for a user to say that their tastes differ greatly from the devs/packagers. I frequently find myself in such a position: I feel a lot of our packages are including a lot more bells and whisles by default than they used to.
But, of course, the response to this is for those of us with more minimalist preferences to rebuild the packages ourselves.

Just to be clear -- the thing I am objecting to is not the idea that the packages can be recompiled without those dependencies. Of course that is a viable choice that can go either way (and typically, Arch trends towards compiling with support for the kitchen sink if it is easy to do).

I am objecting to the idea that the package maintainers somehow don't realize that the dependency for the package *as-is*, is actually not needed. Because this conversation was founded on the idea of using --assume-installed and then modifying the raw pacman database to remove package dependency relationships without recompiling the package. That is exactly the opposite of "I disagree with your subjective build flags".

I guess in the case of gtk3, if one knows that they won't use the printbackends then it's okay to remove the packages to which said printbackends are linked via the shared library loader... this is getting into some dangerous territory though...

Arch Linux

#1 2018-02-13 20:24:04

[SOLVED] Edit pacman database to remove deps from a package

#2 2018-02-13 20:27:48

Re: [SOLVED] Edit pacman database to remove deps from a package

#3 2018-02-13 20:37:26

Re: [SOLVED] Edit pacman database to remove deps from a package

#4 2018-02-14 00:15:33

Re: [SOLVED] Edit pacman database to remove deps from a package

#5 2018-02-14 00:24:15

Re: [SOLVED] Edit pacman database to remove deps from a package

#6 2018-02-14 01:12:11

Re: [SOLVED] Edit pacman database to remove deps from a package

#7 2018-02-14 01:17:59

Re: [SOLVED] Edit pacman database to remove deps from a package

#8 2018-02-14 01:29:18

Re: [SOLVED] Edit pacman database to remove deps from a package

#9 2018-02-14 01:50:00

Re: [SOLVED] Edit pacman database to remove deps from a package

#10 2018-02-14 02:32:25

Re: [SOLVED] Edit pacman database to remove deps from a package

#11 2018-02-14 03:06:08

Re: [SOLVED] Edit pacman database to remove deps from a package

#12 2018-02-14 03:11:16

Re: [SOLVED] Edit pacman database to remove deps from a package

#13 2018-02-14 03:27:44

Re: [SOLVED] Edit pacman database to remove deps from a package

#14 2018-02-14 03:32:23

Re: [SOLVED] Edit pacman database to remove deps from a package

#15 2018-02-14 03:46:37

Re: [SOLVED] Edit pacman database to remove deps from a package

Board footer