pacman and handling of optdepends for dependencies of a package

Soukyuu · 2016-01-10 16:18:52

There should be a way for pacman to print the optdepends of all dependencies of a package, when one is installed.
Alternatively, each package should list their optdepends, even if it's also an optdepend of one of the dependencies already.

Here's an example why:

- at some point in time, you install a package A, that pulls, let's say, kdebase-runtime as its dependency.
- pacman informs you, that kdebase-runtime has certain optdepends
- you install those you need at this point, and forget about it.

- some days/months/years pass
- you decide to install a package B, that has a dependency on kdebase-runtime - let's say, kdenetwork-krdc
- pacman informs you, that the package has the following optdepends: libvncserver for vnc connections, freerdp for rdp connections and kdebase-keditbookmarks for well, bookmarks.
- you install those and go about configuring your host entries
- krdc has support for saving passwords using kwallet, and says so in the UI
- you verify that kwallet is installed, yet passwords are not saved.

- after debugging, you discover that kdepimlibs4 is what krdc needs to save passwords, and doesn't list it as optdepend
- you make a bug report
- it gets closed because it's already an optdepend of kdebase-runtime, which you installed days/months/years ago and thus pacman won't list kdebase-runtime's optdepends, because it only does so when it pulls the package

- attempts to point out the fact get denied with

Scimmia wrote:

By paying attention to what pacman tells them.

Scimmia wrote:

By paying attention when you previously installed kdebase-runtime

Dear Scimmia, if I am required to hold the whole dependency tree of all installed packages in my head at all times, for days/months/years, I might as well not use a packagemanager at all.

Scimmia · 2016-01-10 16:47:41

Soukyuu wrote:

Dear Scimmia, if I am required to hold the whole dependency tree of all installed packages in my head at all times, for days/months/years, I might as well not use a packagemanager at all.

Then don't, what do I care? You're the one that first decided that you didn't want kdebase-runtime to work with kwallet, and now you're regretting that decision. That isn't a packaging problem.

Last edited by Scimmia (2016-01-10 16:48:35)

Soukyuu · 2016-01-10 18:33:06

No I didn't. kwallet integration with kdebase-runtime wasn't needed at that point.
The krdc package doesn't mention either kwalletd as dependency (because it's inside kdebase-runtime), or kdepimlibs4 (because kdebase-runtime was already installed).
The only way I found out it actually needs kwallet is because it says so in the UI.

The idea behind a package manager is to manage dependencies for you. If I install a package, I trust it to pull all the needed dependencies and tell me about anything else I might want.
In this particular case, pacman fails to do so.

What harm does it do to add kdepimlibs4 as optdepend to kdenetwork-krdc? Or list all optdepends of all dependencies of knetwork-krdc?

ewaller · 2016-01-10 18:50:43

If your only tool is a hammer, then every problem looks like a nail.

Soukyuu · 2016-01-10 20:03:11

Really now? Care to contribute any actual arguments against my suggestion?
I expected more than being showered with condescending remarks. Guess I was wrong.

ewaller · 2016-01-10 20:27:22

Arch Linux does not support partial upgrades. Perhaps it is a shortcoming with Arch. But, you are still using the tool for the wrong purpose and that was my point. You are going to break what you are working on, or you are going to break the tool.

If you want this kind of control, you may want to consider Gentoo; Its emerge tool and USE flags may provide for your needs better than does pacman. In the mean time, this is turning into a bikeshed.

arojas · 2016-01-10 20:29:12

Soukyuu wrote:

What harm does it do to add kdepimlibs4 as optdepend to kdenetwork-krdc?

It's not just kdenetwork-krcd. We would need to add it to every KDE4 application that uses kwallet. And what about other optional dependencies? All applications need khelpcenter to display their help, should we add it as an optdepend to every single KDE4 application when it's an optdepend of kdebase-runtime already?
I agree that the situation is not optimal, but I don't think that adding redundant optdepends all over the place is any better.

Soukyuu · 2016-01-10 21:09:05

Right, that's certainly a disadvantage. But in the end, isn't that just a matter of time/workforce?

Also, wouldn't it be possible to make pacman print out optdepends of the dependencies of the package you just installed? I don't know how pacman is handling the dependencies, but walking the dependency tree and printing optdepends shouldn't be a hard thing to do. Of course, for some packages that have large dependency trees it might flood the output, but I certainly prefer that over having to lose time trying to figure out which dependency I might be missing. It could even be made an option for people that don't want pacman to be "verbose".

ewaller wrote:

Arch Linux does not support partial upgrades.

Sorry, you'll have to walk me through on this. Which part of installing kdenetwork-krdc is a partial upgrade? kdebase-runtime was installed as a dependency for kdebase-kdialog in my case. I don't see a partial upgrade anywhere.

Last edited by Soukyuu (2016-01-10 21:12:26)

ewaller · 2016-01-10 21:19:51

You are right, perhaps I misunderstood. My apologies.

apg · 2016-01-10 23:23:09

Soukyuu wrote:

Also, wouldn't it be possible to make pacman print out optdepends of the dependencies of the package you just installed? I don't know how pacman is handling the dependencies, but walking the dependency tree and printing optdepends shouldn't be a hard thing to do. Of course, for some packages that have large dependency trees it might flood the output, but I certainly prefer that over having to lose time trying to figure out which dependency I might be missing. It could even be made an option for people that don't want pacman to be "verbose".

I highly doubt you want pacman to do that during every transaction.

pactree -su kdenetwork-krdc | expac -Sl"\n" %O - | wc -l

gives 89 optional dependencies and that only walks the actual dependencies, not the optional dependencies.

paccheck can recursively check for missing optional dependencies:

paccheck --recursive --opt-depends $pkg

Xyne · 2016-01-11 00:01:15

arojas wrote:

Soukyuu wrote:
What harm does it do to add kdepimlibs4 as optdepend to kdenetwork-krdc?
It's not just kdenetwork-krcd. We would need to add it to every KDE4 application that uses kwallet. And what about other optional dependencies? All applications need khelpcenter to display their help, should we add it as an optdepend to every single KDE4 application when it's an optdepend of kdebase-runtime already?
I agree that the situation is not optimal, but I don't think that adding redundant optdepends all over the place is any better.

Yes.

If a given package requires another for optional functionality then it should be listed as an optdep for that package. It doesn't matter if it recurs across multiple packages that already depend on a common dependency that lists it as an optdep.

The guiding principle should always be technical accuracy. In this case, Pacman fails to inform the user of which dependencies are required for the given functionality. Whether or not it's a PITA to add the optdeps to the PKGBUILDs is irrelevant.

Every so often issues come up due to missing deps and optdeps in the PKGBUILD and the argument is almost always something like "but adding them is tedious" or "but it clutters the PKGBUILD". I get it. It is a PITA, but if that's what it takes for technical correctness than it should be done. If we have a script to update checksums in the PKGBUILD, someone can write a script to insert a list of deps into a template PKGBUILD.

Incidentally the same applies to normal deps (i.e. direct deps should always be listed imo), but that is not an issue as it has no immediate technical consequence.

Given that the current philosophy of "the dep of my dep is my dep", printing out nested optdeps with a user flag would be useful.

@Soukyuu
I understand your frustration but your first post was a bit caustic and poisoned the succeeding discussion. I suspect that is why most replies immediately dismissed your issue without considering it, which is a shame because I believe it has merit. Anyway, please refrain from using such a tone in the future.

Allan · 2016-01-11 00:55:10

Xyne wrote:

If a given package requires another for optional functionality then it should be listed as an optdep for that package. It doesn't matter if it recurs across multiple packages that already depend on a common dependency that lists it as an optdep.
The guiding principle should always be technical accuracy. In this case, Pacman fails to inform the user of which dependencies are required for the given functionality. Whether or not it's a PITA to add the optdeps to the PKGBUILDs is irrelevant.

I agree with Xyne!

This is a case of bad packaging and should be fixed.

jasonwryan · 2016-01-11 01:08:45

Allan wrote:

I agree with Xyne!

Screencapped for posterity!

Xyne · 2016-01-11 02:21:14

Allan wrote:

I agree with Xyne!

Wait, what?

The Hack 2: Phrak Strikes Back?

jasonwryan wrote:

Screencapped for posterity!

I'll be printing that out and framing it.

severach · 2016-01-11 09:25:38

Seblu makes it pretty clear.

1. Put all needed dependencies. You should not assume that another package has the same requirement and do the job for you. It can be dropped without notifying you.

Xyne · 2016-01-11 16:19:58

I agree with nearly all of Seblu's guidelines. I still prefer to cd into the target directory rather than rely on a de-facto standard, which is what indirect dependencies may be said to be.

Regarding my previous post, see here

Scimmia · 2016-01-11 16:28:28

I haven't looked into it very far, but my understanding is that krdc doesn't use kwallet or kdepimlibs4 directly. It calls kdebase-runtime, which then uses kwallet. In this case, adding the dep to krdc would be wrong.

Soukyuu · 2016-01-11 19:26:09

I see what you're saying, but that's not obvious to the user at all. What the user (or well, me) is seeing is that krdc needs kwallet to store the passwords, it is installed, but the integration is not working. Worse yet, it's not working for krdc, but working for other programgs. Digging deeper, you realize that the ones working are the kf5 applications. Of course, in the end you find out what you are missing, but I'd rather have kdrc have that optdepend. Even if it's not 100% correct, it's still 95% more correct than not having that optdepend at all.

apg wrote:

Soukyuu wrote:
Also, wouldn't it be possible to make pacman print out optdepends of the dependencies of the package you just installed? I don't know how pacman is handling the dependencies, but walking the dependency tree and printing optdepends shouldn't be a hard thing to do. Of course, for some packages that have large dependency trees it might flood the output, but I certainly prefer that over having to lose time trying to figure out which dependency I might be missing. It could even be made an option for people that don't want pacman to be "verbose".
I highly doubt you want pacman to do that during every transaction.
pactree -su kdenetwork-krdc | expac -Sl"\n" %O - | wc -l
gives 89 optional dependencies and that only walks the actual dependencies, not the optional dependencies.
paccheck can recursively check for missing optional dependencies:
paccheck --recursive --opt-depends $pkg

I don't really think it should print dependencies, as the non-optional ones will be satisfied by installing the program (unless it's missing one). It's the optional dependencies, however, don't have to be satisfied when installing a program, which leads to the problem I encountered with krdc

Xyne wrote:

If a given package requires another for optional functionality then it should be listed as an optdep for that package. It doesn't matter if it recurs across multiple packages that already depend on a common dependency that lists it as an optdep.
The guiding principle should always be technical accuracy. In this case, Pacman fails to inform the user of which dependencies are required for the given functionality. Whether or not it's a PITA to add the optdeps to the PKGBUILDs is irrelevant.

That's pretty much why I made that bug report in the first place, I'm glad that people agree.

@Soukyuu
I understand your frustration but your first post was a bit caustic and poisoned the succeeding discussion. I suspect that is why most replies immediately dismissed your issue without considering it, which is a shame because I believe it has merit. Anyway, please refrain from using such a tone in the future.

The tone in my post stems solely from people simply dismissing what I was saying in the bug report and the subsequent re-open requests, treating me like someone who was too lazy to read pacman output, while I was trying to be civil.
I'm just glad I haven't posted the original two versions of that post. Maybe I should have cooled down even more before posting, sorry about that.

ewaller wrote:

You are right, perhaps I misunderstood. My apologies.

It could be that I wasn't being clear enough, it happens from time to time. Apology accepted.

apg · 2016-01-11 19:32:05

Soukyuu wrote:

apg wrote:
Soukyuu wrote:
Also, wouldn't it be possible to make pacman print out optdepends of the dependencies of the package you just installed? I don't know how pacman is handling the dependencies, but walking the dependency tree and printing optdepends shouldn't be a hard thing to do. Of course, for some packages that have large dependency trees it might flood the output, but I certainly prefer that over having to lose time trying to figure out which dependency I might be missing. It could even be made an option for people that don't want pacman to be "verbose".
I highly doubt you want pacman to do that during every transaction.
pactree -su kdenetwork-krdc | expac -Sl"\n" %O - | wc -l
gives 89 optional dependencies and that only walks the actual dependencies, not the optional dependencies.
paccheck can recursively check for missing optional dependencies:
paccheck --recursive --opt-depends $pkg
I don't really think it should print dependencies, as the non-optional ones will be satisfied by installing the program (unless it's missing one). It's the optional dependencies, however, don't have to be satisfied when installing a program, which leads to the problem I encountered with krdc

I was only talking about optional dependencies. If you recursively search kdenetwork-krdc's dependencies for optional dependencies there are 89 of them. That is a rather significant amount of output.

ayekat · 2016-01-11 19:57:31

apg wrote:

I was only talking about optional dependencies. If you recursively search kdenetwork-krdc's dependencies for optional dependencies there are 89 of them. That is a rather significant amount of output.

There is no need to put all optdeps of all deps - only the optdeps relevant to the package in question (in this case kwallet and kdepimlibs4).

I agree with Xyne, Seblu and others that everytime one of the dependencies removes an optional dependency, currently this would require a check of all packages that might potentially depend on that optdep (which is not trivial, since none of the packages state so).

Scimmia wrote:

I haven't looked into it very far, but my understanding is that krdc doesn't use kwallet or kdepimlibs4 directly. It calls kdebase-runtime, which then uses kwallet. In this case, adding the dep to krdc would be wrong.

Application plugins don't directly communicate with each others, but through the API given by the main application. Yet some plugins may (optionally) depend on other plugins to be present.
If we treat krdc, kwallet, etc. as "plugins" to the "application" kdebase-runtime¹, even though they don't directly use each others, it would be valid to say that there are dependencies between each other.

____
¹ This is of course a little unconventional way to look at things, but I think it makes this matter more consistent.

Last edited by ayekat (2016-01-11 19:58:14)

Soukyuu · 2016-01-11 20:01:03

Oh, looks like I misread the

gives 89 optional dependencies and that only walks the actual dependencies, not the optional dependencies.

part as 89 non-optional dependencies being listed.

In any case, that was just the alternative to adding those optdepends to the package directly. As (I think) I said in one of my previous posts, I am aware of the flood that would cause with certain packages, so that could be an option. Though it looks like paccheck would be such an "option" in the form of a separate tool. It would still be nice to have it streamlined in one, though.

edit:

ayekat wrote:

apg wrote:
I was only talking about optional dependencies. If you recursively search kdenetwork-krdc's dependencies for optional dependencies there are 89 of them. That is a rather significant amount of output.
There is no need to put all optdeps of all deps - only the optdeps relevant to the package in question (in this case kwallet and kdepimlibs4).

The problem with that is, you'd have to filter them out somehow. It's much easier to just add the respective optdepends to the package directly.

Last edited by Soukyuu (2016-01-11 20:04:20)

ayekat · 2016-01-11 20:07:38

Soukyuu wrote:

The problem with that is, you'd have to filter them out somehow. It's much easier to just add the respective optdepends to the package directly.

Ah yes, I'm sorry, I missed the part where your conversation switched to adding an option to pacman for recursively displaying the optdeps (I was talking about adding the optdeps directly to the package).

Trilby · 2016-01-11 20:20:57

Recursively listing optdeps seems like a horrible idea to me.

Imagine a situation like the one that triggered the thread: you are installing package A which depends on B and you already have B installed. B has many optional dependencies, say X Y and Z that all allow B to do different things. If the behavior of A changes based on whether Y is installed then Y should be an optional dependency of A to get that change in behavior. X and Z might not have any impact at all on A, so recursively listing those irrelevant optdeps would be silly and misleading.

If a package requires a second package to function, then the second package is a dependency of the first. If a package changes it's behavior based on the presence of a second package, then the second package is an optional dependency.

We tend not to list dependencies that are already required by other dependencies. This is only for keeping the dependency list clean, and it is a convenience allowed for by the fact that a dep of a dep will necessarily already be installed. This does not apply to optdeps of deps*, so we cannot take advantage of this convenience here: optional dependencies (defined as in my previous paragraph) should be listed.

*note we also cannot tage advantage of this convencience for deps of optdeps. Say package A required package Y in order to function. Package Y is then a dependency of A. But if Y was also a dependency of B, and B was only an optional dependency of A, could we leave Y off of A's depends list? Of course not. The convenient trimming of dependency lists applies only to full dependencies of full dependencies.

Xyne · 2016-01-11 20:36:11

Soukyuu wrote:

The tone in my post stems solely from people simply dismissing what I was saying in the bug report and the subsequent re-open requests, treating me like someone who was too lazy to read pacman output, while I was trying to be civil.

I fully sympathize. Both online and off, its human nature to tend to dismiss the concerns and recommendations of "outsiders" due to textbook groupthink. It's annoying as f@#%. The best way to get through is to maintain your calm and overtly show them why they're wrong (or humbly learn why you are ). Once others begin to lend weight to your arguments, they will often be reconsidered.

Anyway, there's no issue with this thread. It was just a remark to ensure smooth sailing on the forum.

Allan · 2016-01-11 21:28:39

Xyne wrote:

I still prefer to cd into the target directory rather than rely on a de-facto standard

It is a documented standard with makepkg-5.0.

Arch Linux

#1 2016-01-10 16:18:52

pacman and handling of optdepends for dependencies of a package

#2 2016-01-10 16:47:41

Re: pacman and handling of optdepends for dependencies of a package

#3 2016-01-10 18:33:06

Re: pacman and handling of optdepends for dependencies of a package

#4 2016-01-10 18:50:43

Re: pacman and handling of optdepends for dependencies of a package

#5 2016-01-10 20:03:11

Re: pacman and handling of optdepends for dependencies of a package

#6 2016-01-10 20:27:22

Re: pacman and handling of optdepends for dependencies of a package

#7 2016-01-10 20:29:12

Re: pacman and handling of optdepends for dependencies of a package

#8 2016-01-10 21:09:05

Re: pacman and handling of optdepends for dependencies of a package

#9 2016-01-10 21:19:51

Re: pacman and handling of optdepends for dependencies of a package

#10 2016-01-10 23:23:09

Re: pacman and handling of optdepends for dependencies of a package

#11 2016-01-11 00:01:15

Re: pacman and handling of optdepends for dependencies of a package

#12 2016-01-11 00:55:10

Re: pacman and handling of optdepends for dependencies of a package

#13 2016-01-11 01:08:45

Re: pacman and handling of optdepends for dependencies of a package

#14 2016-01-11 02:21:14

Re: pacman and handling of optdepends for dependencies of a package

#15 2016-01-11 09:25:38

Re: pacman and handling of optdepends for dependencies of a package

#16 2016-01-11 16:19:58

Re: pacman and handling of optdepends for dependencies of a package

#17 2016-01-11 16:28:28

Re: pacman and handling of optdepends for dependencies of a package

#18 2016-01-11 19:26:09

Re: pacman and handling of optdepends for dependencies of a package

#19 2016-01-11 19:32:05

Re: pacman and handling of optdepends for dependencies of a package

#20 2016-01-11 19:57:31

Re: pacman and handling of optdepends for dependencies of a package

#21 2016-01-11 20:01:03

Re: pacman and handling of optdepends for dependencies of a package

#22 2016-01-11 20:07:38

Re: pacman and handling of optdepends for dependencies of a package

#23 2016-01-11 20:20:57

Re: pacman and handling of optdepends for dependencies of a package

#24 2016-01-11 20:36:11

Re: pacman and handling of optdepends for dependencies of a package

#25 2016-01-11 21:28:39

Re: pacman and handling of optdepends for dependencies of a package

Board footer