???? ghost module - Porteus bug?

[Ed_P]

Code: Select all

guest@porteus:~$ ls -hon /mnt/live/memory/images | grep mpv 
guest@porteus:~$ 

guest@porteus:~$ sudo activate /mnt/nvme0n1p7/porteus5.0/Optional/mpv*.xzm
Password: 
Updating shared library links:  /sbin/ldconfig
Updating menu
Updating desktop database
guest@porteus:~$ 

guest@porteus:~$ ls -hon /mnt/live/memory/images | grep mpv 
drwxr-xr-x  5 0  48 Jun 16  2018 mpv-0.27.2-x86_64-2_SBo.xzm/
drwxr-xr-x  6 0  71 Feb  7 16:55 mpv-0.34.1-x86_64-1gv.xzm/
guest@porteus:~$

guest@porteus:~$ ls -hon /mnt/nvme0n1p7/porteus5.0/Optional | grep mpv 
-rwxrwxrwx 1 1000  33M Feb  7 16:55 mpv-0.34.1-x86_64-1gv.xzm*

guest@porteus:~$ ls -hon /mnt/nvme0n1p7/porteus5.0/Modules | grep mpv 
guest@porteus:~$ 

Where did mpv-0.27.2-x86_64-2_SBo.xzm come from??

Added in 5 hours 30 minutes 17 seconds:

Code: Select all

guest@porteus:/mnt/nvme0n1p7/porteus5.0/Optional$ find . mpv* | grep mpv
./mpv-0.34.1-x86_64-1gv.xzm
mpv-0.34.1-x86_64-1gv.xzm
guest@porteus:/mnt/nvme0n1p7/porteus5.0/Optional$ 

Still only the 0.34 file found. The mystery continues.

Added in 26 minutes :
On the drive in an old, different folder, the 0.27 module exists:

Code: Select all

guest@porteus:~$ ls -hon /mnt/nvme0n1p7/porteus4.0/Optional | grep mpv
-rwxrwxrwx 1 1000 1.3M Jun 23  2018 mpv-0.27.2-x86_64-2_SBo.xzm*
guest@porteus:~$ 

But why/how would an activate command for the one in the porteus5.0 folder activate the one in the porteus4.0 folder??? Bug?

[Brequir1992]

Added in 26 minutes :
On the drive in an old, different folder, the 0.27 module exists:

Code: Select all

guest@porteus:~$ ls -hon /mnt/nvme0n1p7/porteus4.0/Optional | grep mpv
-rwxrwxrwx 1 1000 1.3M Jun 23  2018 mpv-0.27.2-x86_64-2_SBo.xzm*
guest@porteus:~$

But why/how would an activate command for the one in the porteus5.0 folder activate the one in the porteus4.0 folder??? Bug?

I had a similar issue once, and it drove me crazy for hours. Modules were loading from places I didn’t expect, and no matter what I did, the system kept picking up an older version. After a lot of trial and error, I finally realized that understanding how dependencies and paths are managed is key. Funny enough, I ran into a comparable problem while working on debugging unexpected behavior in an app felt just like chasing down rogue modules. In both cases, once I figured out the right approach, I saved so much time. Just wanted to share in case it helps!

Have you tried manually deactivating all mpv modules, deactivate mpv , ensuring none are loaded, and then activating only the new one again? Also, is there any chance the old module is being cached somewhere, or could there be a symlink pointing to the old directory? I ran into something similar once with another package, and it turned out the system was referencing an outdated library path. I had to manually clean up old references and update my paths. Maybe check ldd $ which mpv to see if it's loading any unexpected libraries?

https://www.cogniteq.com/flutter-app-development helped me with similar issue, they presents its own set of challenges when dealing with dependencies especially when working with native modules in frameworks like React Native or Flutter. Sometimes, even after updating dependencies, an app may still load outdated versions due to build caching or incorrect linking. Clearing caches, rebuilding from scratch, or even manually resolving dependency conflicts can often do the trick!