Interesting dependency issue [Possible bug]?

merlock · 2020-11-20 15:46:57

So, I was trying to help squash bugs with the new version of opencl-amd, and discovered this possible problem.

I installed blender, and also the needed 27 dependencies:

So, it seems that my card doesn't have enough VRAM (so much for helping), and having no other use for blender, go to uninstall it.

Well, blender wanted to take 3 additional dependencies that were previously installed as opt-deps for other packages (specifically jasper, libraw and openexr). Since "-R" doesn't have an ignore option, the only way I could see out of this was to declare those 3 "asexplicit", remove blender (removed the proper packages from above), then re-mark those 3 "asdeps", which will probably delegate them to the orphanage (they are not there right now).

So, I guess the question is: Why did blender want to remove previously installed packages?

Scimmia · 2020-11-20 15:51:10

How would it know that they were previously installed?

Trilby · 2020-11-20 15:51:37

Blender didn't "want" to do anything. I'd gather you used the used the -s flag with -R (but you really should provide the actual commands used). And because jasper and libraw were (apparently) installed as dependencies, but not required by any package, they were orphans and would be removed.

Don't remark those three as "asdeps" unless you want them removed again next time you remove a package.

If you really want to keep packages installed and marked as dependencies (when they are only optional) then you could do the following, but I'd not advise it:

pacman -Rn blender
pacman -Qdtq | pacman -Rn -
# you might have to repeat this second a few times

Last edited by Trilby (2020-11-20 16:31:05)

merlock · 2020-11-20 16:40:05

Scimmia wrote:

How would it know that they were previously installed?

[2019-07-03 00:33] [PACMAN] Running 'pacman -r /mnt -Sy --cachedir=/mnt/var/cache/pacman/pkg --noconfirm base base-devel grub'

...

[2019-07-03 22:49] [ALPM] installed jasper (2.0.16-1)

[2019-11-06T18:08:29-0500] [ALPM] installed libraw (0.19.5-2)

[2019-11-06T18:08:30-0500] [ALPM] installed openexr (2.4.0-4)

Trilby wrote:

Blender didn't "want" to do anything. I'd gather you used the used the -s flag with -R (but you really should provide the actual commands used).

Command was "-Rns".

Trilby wrote:

And because jasper and libraw were (apparently) installed as dependencies, but not required by any package, they were orphans and would be removed.

pacman -Qi imagemagick
Name            : imagemagick
Version         : 7.0.10.39-1
Description     : An image viewing/manipulation program
Architecture    : x86_64
URL             : https://www.imagemagick.org/
Licenses        : custom
Groups          : None
Provides        : libmagick
Depends On      : libltdl  lcms2  fontconfig  libxext  liblqr  libraqm  libpng  libxml2
Optional Deps   : ghostscript: PS/PDF support [installed]
                  libheif: HEIF support [installed]
                  libraw: DNG support [installed]
                  librsvg: SVG support [installed]
                  libwebp: WEBP support [installed]
                  libwmf: WMF support [installed]
                  libxml2: Magick Scripting Language [installed]
                  ocl-icd: OpenCL support [installed]
                  openexr: OpenEXR support [installed]
                  openjpeg2: JPEG2000 support [installed]
                  djvulibre: DJVU support
                  pango: Text rendering [installed]
                  imagemagick-doc: manual and API docs
Required By     : cups-filters  i3exit
Optional For    : feh  kitty  neofetch  pacgraph  python-sphinx
Conflicts With  : imagemagick6
Replaces        : imagemagick6  libmagick
Installed Size  : 9.81 MiB
Packager        : Antonio Rojas <arojas@archlinux.org>
Build Date      : Wed 18 Nov 2020 02:08:28 AM EST
Install Date    : Wed 18 Nov 2020 07:02:26 AM EST
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

So, does this imply that imagemagick's optional dependency of openexr mean that in fact, openexr is an orphan?

Oh, and currently:

pacman -Qdtq
expac
signify

ETA: Terminal commands WRT blender.

blender installation

blender removal

Last edited by merlock (2020-11-20 16:56:00)

Trilby · 2020-11-20 16:51:47

merlock wrote:

<random pacman log entries>

You do realize that pacman is not a sentient intelligence reading the log and making inferences about what you probably meant when you issued a command, right? The pacman database does not store which package a dependency was installed with, so when you try to remove it, it gets removed if it is not needed by anything else.

merlock wrote:

Command was "-Rns".

Well, no, that is not a complete command. But that's neither here nor there now - we can infer what the command actually was from the context. My point was we should not have to.

merlock wrote:

<random pacman -Qi output>
So, does this imply that imagemagick's optional dependency of openexr mean that in fact, openexr is an orphan?

No. That output tells you aboubt imagemagick. If you want to know about openexr, you should probably run `pacman -Qi openxr`.

merlock · 2020-11-20 17:01:02

Trilby wrote:

You do realize that pacman is not a sentient intelligence reading the log and making inferences about what you probably meant when you issued a command, right? The pacman database does not store which package a dependency was installed with, so when you try to remove it, it gets removed if it is not needed by anything else.

Yes, I do. You ninja'd me. Please see above for the actual install and removal screens.

ETA: This install/remove is within the last 30 minutes.

Last edited by merlock (2020-11-20 17:02:07)

Trilby · 2020-11-20 17:18:44

And what are "install and remove screens" supposed to show. We all know what pacman output looks like.

Is you're question really whether there's a bug? NO, there isn't. Pacman's doing precisely what it is supposed to. It even asked if you wanted to remove those packages - if you say yes, then it will remove those packages.

merlock · 2020-11-20 17:54:39

I guess this is a candidate for TGN.

Trilby wrote:

It even asked if you wanted to remove those packages

And it info'd me that it's removing packages optionally required by a different package.

This is what I'm not getting my head around.

Scimmia · 2020-11-20 18:18:49

"optionally required" is not required.

GaKu999 · 2020-11-20 18:19:05

Simple summary:
Opt dep is not hard dep, opt dep installed as dep by package that haves it as hard dep is what I call, transient dep.

If said package is removed without -s, opt dep and possibly orphans will be left behind, marked as dep.

Both have nearly no differences in an abstract way, since an opt dep should be installed explicitly, not pulled in a transient way by an unrelated package.

And the remedy for such situation is, prompt the user, and user must mark wanted leftovers as explicit.

Ooor, just remove stuff with -s, so you don’t get orphan mess, and install opt dep as explicit.

pacman does nor care if the user messed up the dep tree, it sees deps that are not hard dep, and considers them for removal, that’s it.

Honestly this is the wall of text version of Scimmia’s ^

Last edited by GaKu999 (2020-11-20 18:20:34)

Trilby · 2020-11-20 18:49:44

GaKu999 wrote:

... an opt dep should be installed explicitly

Perhaps this is the OPs confusion as they are (for some reason) intentionally marking these "asdeps". I did just find a note in the wiki that suggests this - but I think its bad advice and goes against everything I've heard elsewhere in this community:
https://wiki.archlinux.org/index.php/Pa … g_packages

wiki wrote:

When installing a package which you require only as (optional) dependency of some other package (i.e. not required by you explicitly otherwise), it is recommended to use --asdeps option.

Aparently, this note has been in what should be a well-reviewed page of the wiki for two years.

eschwartz · 2020-11-20 19:10:42

If you install it with --asdeps then you can check for orphans in a slightly more thorough way. I have a pyalpm script which prints:

Packages with no requires/opt requires:
  [...]
Packages with opt requires but no requires:
  [...]

And I could choose to keep something installed only because it is an optdepend of another package, but if I remove the other package, I might want to purge this too.

The real topic of discussion here, I think, is that the OP wanted *an option* for pacman to treat "asdeps" packages which are orphaned once blender is removed, but still have reverse optdepends, to be skipped from being uninstalled. Or else to be prompted if you want to add this to the removal transaction.

Meanwhile, users are free to use --asdeps or --asexplicit to decide whether they want pacman to err in favor of either removing the package, or keeping the package.

Other options include private PKGBUILDs that create metapackages depending on the packages you want installed for whichever reason. Then these optdepends won't ever be orphaned.

merlock · 2020-11-21 00:20:15

eschwartz wrote:

The real topic of discussion here, I think, is that the OP wanted *an option* for pacman to treat "asdeps" packages which are orphaned once blender is removed, but still have reverse optdepends, to be skipped from being uninstalled. Or else to be prompted if you want to add this to the removal transaction.

This is pretty close, @eschwartz. Or, even leave any pre-existing packages alone. But, at one point in time (6 Nov 2019), libraw was a required dependency of one of these programs that were upgraded:

[2019-11-06T18:08:19-0500] [PACMAN] Running 'pacman -Syu'
[2019-11-06T18:08:19-0500] [PACMAN] synchronizing package lists
[2019-11-06T18:08:20-0500] [PACMAN] starting full system upgrade
[2019-11-06T18:08:28-0500] [ALPM] running '50-pacman-list.hook'...
[2019-11-06T18:08:28-0500] [ALPM] transaction started
[2019-11-06T18:08:29-0500] [ALPM] upgraded adwaita-icon-theme (3.34.1-1 -> 3.34.2-1)
[2019-11-06T18:08:29-0500] [ALPM] installed libde265 (1.0.3-1)
[2019-11-06T18:08:29-0500] [ALPM] installed libheif (1.5.1-2)
[2019-11-06T18:08:29-0500] [ALPM] installed libwmf (0.2.12-1)
[2019-11-06T18:08:29-0500] [ALPM] installed libraw (0.19.5-2)
[2019-11-06T18:08:30-0500] [ALPM] installed openexr (2.4.0-4)
[2019-11-06T18:08:30-0500] [ALPM] upgraded imagemagick (7.0.9.2-1 -> 7.0.9.2-2)
[2019-11-06T18:08:30-0500] [ALPM] upgraded libva-mesa-driver (19.2.2-1 -> 19.2.3-1)
[2019-11-06T18:08:30-0500] [ALPM] upgraded mariadb-libs (10.4.8-2 -> 10.4.9-1)
[2019-11-06T18:08:31-0500] [ALPM] upgraded mesa (19.2.2-1 -> 19.2.3-1)
[2019-11-06T18:08:31-0500] [ALPM] upgraded mesa-vdpau (19.2.2-1 -> 19.2.3-1)
[2019-11-06T18:08:31-0500] [ALPM] upgraded opencl-mesa (19.2.2-1 -> 19.2.3-1)
[2019-11-06T18:08:32-0500] [ALPM] upgraded python-sphinx (2.2.0-1 -> 2.2.1-1)
[2019-11-06T18:08:32-0500] [ALPM] upgraded vulkan-mesa-layer (19.2.2-1 -> 19.2.3-1)
[2019-11-06T18:08:32-0500] [ALPM] upgraded vulkan-radeon (19.2.2-1 -> 19.2.3-1)
[2019-11-06T18:08:33-0500] [ALPM] upgraded webkit2gtk (2.26.1-1 -> 2.26.2-1)
[2019-11-06T18:08:33-0500] [ALPM] transaction completed
[2019-11-06T18:08:33-0500] [ALPM] running '30-systemd-update.hook'...
[2019-11-06T18:08:33-0500] [ALPM] running 'detect-old-perl-modules.hook'...
[2019-11-06T18:08:33-0500] [ALPM] running 'gdk-pixbuf-query-loaders.hook'...
[2019-11-06T18:08:33-0500] [ALPM] running 'gtk-update-icon-cache.hook'...
[2019-11-06T18:08:33-0500] [ALPM] running 'systemd-uesync.hook'...
[2019-11-06T18:08:33-0500] [ALPM] running 'update-mime-database.hook'...

Please note that I did not manually install libraw on my own volition. IIRC, an optional depend is never automatically installed - pacman will give you a "foo is optionally required by bar" info line. So, my reasoning is that libraw was required at one time, but somewhere along the line, it was dropped to being an optional.

As an aside: other than today, the only time I've messed with 'asdeps' was when Arch got rid of the 'base' group.

Ok, I'll shut up now; I seem to be making a mountain out of a molehill.

GaKu999 · 2020-11-21 06:26:45

From a different perspective, as said by eschwartz, the goal of this thread would be the creation of more flags (or change the current ones) for -R so that it allows fine grained control on the type of dependency, thus, allowing to recursively wipe orphans, leaving opt deps there, or include the opt deps as well.

That would be similar in nature to -t and -tt of -Q.

Of course, that is a noop that I assume because pacman’s option syntax hasn’t received that much changes in a while (assumption made from my 4 minutes of looking up the log, disregard if this is bogus info).
Note: noop because of backwards support, maybe with scripts or whatnot. Or who knows, I’m not a pacman dev, just making an assumption about the intended stability of its CLI

The option suggested by Trilby also works, tho it’s not as effective as a good o’l -Rs. I once tried that approach for dep management, until I decided to make opts as explicit. (easier to nuke cruft with -Rns)

Once in a while (or after a rush install), I iterate over the explicit packages, nuking ones that seem to be left behind opt deps marked as explicit.

In any case, bonus points to pacman for always asking, it’s unlikely to end up wiping something unless you hit <enter> like candy is going to pop out after 1000 hits. (or use —nocomfirm)

Last edited by GaKu999 (2020-11-21 06:31:41)

Lone_Wolf · 2020-11-21 12:04:21

Some changes in pacman syntax I remember :

- removal of --force
- introduction of --overwrite
- additioial feature with its own sub-options : -F / --files

eschwartz · 2020-11-22 04:21:59

GaKu999 wrote:

Of course, that is a noop that I assume because pacman’s option syntax hasn’t received that much changes in a while (assumption made from my 4 minutes of looking up the log, disregard if this is bogus info).
Note: noop because of backwards support, maybe with scripts or whatnot. Or who knows, I’m not a pacman dev, just making an assumption about the intended stability of its CLI

...

What.

Is that a thing some projects do? Refuse to add new options because it would break "the intended stability of its CLI" for something that was previously "error: invalid option" to become a valid option that does something?

Pacman syntax is obviously not going to change currently valid syntax to silently do something entirely different from what it currently does. That's stability. We won't suddenly decide one day that you upgrade with -Wdym, and make -S modify all packages' install reasons, -y to asdeps, -u only if they currently have reverse depends rather than being leaf packages.

I simply don't get why you think failure to actively decide on much of interest to add or remove, is evidence that per policy, it's forbidden to add or remove anything...

GaKu999 · 2020-11-22 07:35:01

I simply don't get why you think failure to actively decide on much of interest to add or remove, is evidence that per policy, it's forbidden to add or remove anything...

Mostly that is at fault of my poor explanation and reasoning, that’s why I added a note just in case I was just saying BS.

That's stability. We won't suddenly decide one day that you upgrade with -Wdym, and make -S modify all packages' install reasons, -y to asdeps, -u only if they currently have reverse depends rather than being leaf packages.

TBH, I wanted to communicate this exact idea, I think I failed utterly. o_O

I decided to do so since the implementation of changing how -s works in -R would decided, well, to change the whole behavior of the option, as LW stated, most changes that have beed necessary have been removal of bogus options, with a better replacement, (and we can agree that overwrite is better than force), and the addition of the whole of -F.

Anyways I wouldn’t call it failure, I don’t see failure in the current development.

In any way, I just didn’t imagine a way of making -Rs behave like OP wanted, without leaving loopholes in the way, since there’s -s and -ss already.
Is it acceptable to change how -Rs works to manage better the branching not-Required opt deps?

...

Now that I think of it, -o sounds like a healthy addition to -R, and the behavior is, ignore opt deps that are not-Required. Thus, minimal changes. But TBH, again, I can’t imagine proper interaction with the other -R options.
Someone likes my -o suggestion?
Or it could be -t, one already used sort-of for something similar in -Q.

Last edited by GaKu999 (2020-11-22 07:38:36)

Arch Linux

#1 2020-11-20 15:46:57

Interesting dependency issue [Possible bug]?

#2 2020-11-20 15:51:10

Re: Interesting dependency issue [Possible bug]?

#3 2020-11-20 15:51:37

Re: Interesting dependency issue [Possible bug]?

#4 2020-11-20 16:40:05

Re: Interesting dependency issue [Possible bug]?

#5 2020-11-20 16:51:47

Re: Interesting dependency issue [Possible bug]?

#6 2020-11-20 17:01:02

Re: Interesting dependency issue [Possible bug]?

#7 2020-11-20 17:18:44

Re: Interesting dependency issue [Possible bug]?

#8 2020-11-20 17:54:39

Re: Interesting dependency issue [Possible bug]?

#9 2020-11-20 18:18:49

Re: Interesting dependency issue [Possible bug]?

#10 2020-11-20 18:19:05

Re: Interesting dependency issue [Possible bug]?

#11 2020-11-20 18:49:44

Re: Interesting dependency issue [Possible bug]?

#12 2020-11-20 19:10:42

Re: Interesting dependency issue [Possible bug]?

#13 2020-11-21 00:20:15

Re: Interesting dependency issue [Possible bug]?

#14 2020-11-21 06:26:45

Re: Interesting dependency issue [Possible bug]?

#15 2020-11-21 12:04:21

Re: Interesting dependency issue [Possible bug]?

#16 2020-11-22 04:21:59

Re: Interesting dependency issue [Possible bug]?

#17 2020-11-22 07:35:01

Re: Interesting dependency issue [Possible bug]?

Board footer