Disable Thunar's unusable "Set as wallpaper" context menu item.

johnraff · 2016-03-18 06:28:55

You guys seem to be redoing some of the stuff I did earlier. 'gcc -print-multiarch' and 'dpkg-architecture -qDEB_HOST_MULTIARCH' both show up in the OP, and post 12 has:

dpkg -L apt | sed -nr '/libapt-private.so/ {s|^(/usr/lib/[^/]+).*$|\1|p;q0};${q1}'

which is doing the same thing as dpkg -L $thatpackage | grep '/$soname.so$'

I chose apt's libapt-private.so but it could be anything as long as it's an essential package that's guaranteed to be on the system. Of all the packages that use that library path in a BL install apt seemed the most likely to be available when installing a package. libabt-private.so.0.0 and libabt-private.so.0.0.0 are included in apt in all architectures in jessie also in stretch and sid so maybe it's OK to count on having that file available for checking the path?

--------------------------
Unfortunately the multiarch triplets (or tuples) don't follow those GNU names in every case, eg i386.
On Wheezy /usr/share/dpkg/cputable is (edited)

# <Debian name>	<GNU name>	<config.guess regex>	<Bits>	<Endianness>
i386		i486		(i[3456]86|pentium)	32	little
amd64		x86_64		x86_64			64	little
arm		arm		arm.*			32	little

and on Jessie

i386		i586		(i[34567]86|pentium)	32	little
amd64		x86_64		x86_64			64	little
arm		arm		arm.*			32	little

and that cputable/awk code outputs on an i386 VM: 'i586-linux-gnu' where what is needed is 'i386-linux-gnu'. On Wheezy it would output 'i486...'
The Debian Wiki posts this table:

Debian_architecture_name multiarch_name
amd64                             x86_64-linux-gnu 
armhf                              arm-linux-gnueabihf
i386                                i386-linux-gnu

Not every triplet ends in -linux-gnu, and armhf isn't even mentioned in /usr/share/dpkg/cputable.

Last edited by johnraff (2016-03-19 02:00:12)

johnraff · 2016-03-19 02:14:08

BTW the list of possible install paths for files named libapt-private.so* on sid is a handy reference for the multiarch tuples associated with Debian names of architectures. This might be more reliable than the wiki since it's about real packages and gives an idea of what's coming up in Stable in the future.

Some examples:

arm-linux-gnueabihf [armhf]
i386-gnu [hurd-i386]
i386-kfreebsd-gnu [kfreebsd-i386]
i386-linux-gnu [i386]
x86_64-linux-gnu [amd64]
x86_64-kfreebsd-gnu [kfreebsd-amd64]

--------------------

Debian Wiki Multiarch/Tuples

To avoid divergent embedded implementations of architecture->tuple mappings in every piece of software that wants to make use of these paths, a standard commandline tool that encapsulates this mapping should be provided, similar to the config.guess and config.sub tools that are a standard part of GNU autotools. We recommend a name of lsb_architecture for this tool.

But there doesn't seem to be any such tool yet, although lsb-base started to get multiarch in Ubuntuland ~2011.

Last edited by johnraff (2016-03-19 07:40:26)

johnraff · 2016-03-20 03:31:41

...of course, when you think about it the whole purpose of these multi-arch library paths is to allow files associated with several different architectures to coexist on the same system. At the very least, it's quite common for amd64 systems to have i386 packages installed, so any methods which look for a unique directory name matching the multiarch tuples will fail. At the same time it's not 100% guaranteed that the package chosen for a test file will be of the same architecture as libthunarx-2-0 (although it does seem a bit unlikely that apt's architecture will be different).

I had hoped bunsen-thunar would not need to be dependent on Thunar (so it could remain even if Thunar was removed) but perhaps the only clean and safe way to go about this will be:
Add

Depends: libthunarx-2-0

to the control file, and use

dpkg -L libthunarx-2-0 | grep '/usr/lib/.*/thunar-wallpaper-plugin.so'

to get the path to thunar-wallpaper-plugin.so

...as has already been suggested:

nobody wrote:

OR just get the library path from the package itself, which has to be installed anyway before the diversion if it's declared as a dependency.

Shall we go with this?

Last edited by johnraff (2016-03-20 03:35:16)

xaos52 · 2016-03-20 09:39:46

...of course, when you think about it the whole purpose of these multi-arch library paths is to allow files associated with several different architectures to coexist on the same system. At the very least, it's quite common for amd64 systems to have i386 packages installed, so any methods which look for a unique directory name matching the multiarch tuples will fail. At the same time it's not 100% guaranteed that the package chosen for a test file will be of the same architecture as libthunarx-2-0 (although it does seem a bit unlikely that apt's architecture will be different).

Some really good thinking there ...
Can't find any arguments with that.

Shall we go with this?

OK with me.

johnraff · 2016-03-21 06:12:37

bunsen-thunar 8.0-1 now on GitHub: https://github.com/BunsenLabs/bunsen-thunar
@nobody, when you have a moment, if you could build this and put it in the repo?

(I think it's been debugged - survives upgrades, and removal of libthunarx-2-0 is handled OK.)

nobody · 2016-03-21 10:20:09

Was out for some 花見 (a bit too early still after all) but it's now been uploaded.

johnraff · 2016-03-22 03:13:37

@nobody thank you.
(btw bunsen-pipemenus was upgraded to 8.8.3-1 a while ago but seems to have slipped through the net.)

@hhh could you add bunsen-thunar to the install list?

((Sakura will peak next weekend or so I guess.))

Last edited by johnraff (2016-03-22 03:14:01)

nobody · 2016-03-22 12:50:59

johnraff wrote:

(btw bunsen-pipemenus was upgraded to 8.8.3-1 a while ago but seems to have slipped through the net.)

Fixed: uploaded.

xaos52 · 2016-03-22 16:09:15

Re: bunsen-thunar

I was not intimately familiar with dpkg-divert, so I browsed the dpkg sources a bit and found this:

dpkg debugging.

For ex. debug installation of bunsen-thunar:

sudo dpkg -i -D42413 bunsen-thunar |& tee ./install.log

to see in detail what dpkg is doing to install the package, and in what order it is doing this. When is it calling the postinst maintainer script? With what arguments?

You can control what debugging info you are interested in by composing your own -D parameter (setting your own flags):

See

dpkg -Dh

for details.

Might also be helpful when you have packages that won't install because apt finds conflicting info.

nobody · 2016-03-22 16:26:39

The arguments passed to the maintainer scripts are clearly documented in the Debian package maintainer's manual. No essential need to do forensics, just exercise ;^)

xaos52 · 2016-03-22 17:09:04

No essential need to do forensics, just exercise

Not essential, no, but ultimately authoritative. Sometimes revealing interesting details.

johnraff · 2016-03-23 02:11:15

nobody wrote:

The arguments passed to the maintainer scripts are clearly documented in the Debian package maintainer's manual.

And elsewhere. Even though I've read that stuff and understand (I think) what concerns us here, @xaos your info is interesting and useful - thank you.

TBH I was a little concerned that uninstalling libthunarx-2 might make bunsen-thunar's prerm script exit with an error because of a missing file (thus making bunsen-thunar unremovable). A test showed that dpkg does the right thing by uninstalling bunsen-thunar first, when libthunarx-2's file is still present (libthunarx-2 is a dependency of bunsen-thunar). Good for dpkg!

Currently prerm has this:

file_package=libthunarx-2-0
filename='thunarx-2/thunar-wallpaper-plugin.so' # path after multiarch tuple

file=$(dpkg -L "$file_package" | grep "^/usr/lib/[^/]\+/$filename\$") || {
    echo "$0: $filename not listed by $file_package" >&2
    exit 1
}

before going on to remove the diversion. I wonder if in the (extremely unlikely) case of not being able to find thunarx-2/thunar-wallpaper-plugin.so it might be better just to output an error message explaining the diversion couldn't be removed, and exit 0? At least removal of bunsen-thunar would be possible, but who knows what state the diversion would be in? Or maybe better the way it is, exit 1 and force the user to investigate the problem?

Last edited by johnraff (2016-03-23 07:59:14)

Head_on_a_Stick · 2016-03-23 07:29:10

johnraff wrote:

exit 1 and force the user to investigate the problem?

^ This, with a clear error message.

Great work you're all doing here btw, I'm learning loads from this thread

Eraph · 2016-03-23 08:12:14

+1, it's a fascinating insight for us outsiders too - who knows, there may be future Bunsen contributors in the audience.

xaos52 · 2016-03-23 14:21:27

before going on to remove the diversion. I wonder if in the (extremely unlikely) case of not being able to find thunarx-2/thunar-wallpaper-plugin.so it might be better just to output an error message explaining the diversion couldn't be removed, and exit 0? At least removal of bunsen-thunar would be possible, but who knows what state the diversion would be in? Or maybe better the way it is, exit 1 and force the user to investigate the problem?

You must exit with exit code 1 (Well, different from zero )
If you exit with code 0, dpkg considers the maintainer script encountered no problems and will consider the package uninstalled, but the diversion will still be there!

This can easily be tested

With exit 1

Thunar related packages installed before the test:

dpkg -l | grep thunar
ii  bunsen-thunar                         8.0-1 
ii  libthunarx-2-0                        1.6.3-2 
ii  thunar                                1.6.3-2 
ii  thunar-data                           1.6.3-2 
ii  thunar-volman                         0.8.0-4

Edit /var/lib/dpkg/info/bunsen-thunar.prerm
I changed line defining filename to

filename='thunarx-2/thunar-wallpaperx-plugin.so' # path after multiarch tuple

-- Notice 'wallpaperx'

Running apt-get remove libthunarx-2-0

 /h/m/t/t/bunsen-thunar _ apt-get remove libthunarx-2-0
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following package was automatically installed and is no longer required:
  thunar-data
Use 'apt-get autoremove' to remove it.
The following packages will be REMOVED:
  bunsen-thunar libthunarx-2-0
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
After this operation, 312 kB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 194600 files and directories currently installed.)
Removing bunsen-thunar (8.0-1) ...
/var/lib/dpkg/info/bunsen-thunar.prerm: thunarx-2/thunar-wallpaperx-plugin.so not listed by libthunarx-2-0
dpkg: error processing package bunsen-thunar (--remove):
 subprocess installed pre-removal script returned error exit status 1
dpkg: libthunarx-2-0: dependency problems, but removing anyway as you requested:
 bunsen-thunar depends on libthunarx-2-0.

Removing libthunarx-2-0 (1.6.3-2) ...
Processing triggers for libc-bin (2.19-18+deb8u3) ...
Errors were encountered while processing:
 bunsen-thunar
E: Sub-process /usr/bin/dpkg returned an error code (1)

-- Notice the error message '... not listed by ...'

Status of involved packages:

dpkg -l | grep thunar
ri  bunsen-thunar                         8.0-1              
rc  libthunarx-2-0                        1.6.3-2            
rc  thunar                                1.6.3-2            
ii  thunar-data                           1.6.3-2            
rc  thunar-volman                         0.8.0-4

Status of bunsen-thunar diversion

 /h/m/t/t/bunsen-thunar dpkg-divert --list '*' | grep thunar
diversion of /usr/lib/x86_64-linux-gnu/thunarx-2/thunar-wallpaper-plugin.so to /usr/lib/x86_64-linux-gnu/thunarx-2/thunar-wallpaper-plugin.so.bunsen-disabled by bunsen-thunar

Conclusion:
- Packages are still there, but unusable. Package files were removed
- For bunsen-thunar the files are still there (because the maintainer script exited with 1
- the bunsen-thunar diversion is still there

Trying to install thunar now gives:

 /h/m/t/t/bunsen-thunar _ apt-get install  thunar
Reading package lists... Done
Building dependency tree       
Reading state information... Done
You might want to run 'apt-get -f install' to correct these:
The following packages have unmet dependencies:
 bunsen-thunar : Depends: libthunarx-2-0 but it is not going to be installed
 thunar : Depends: libthunarx-2-0 (>= 1.1.0) but it is not going to be installed
          Recommends: thunar-volman but it is not going to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).

Running apt-get -f install, as recommende

 /h/m/t/t/bunsen-thunar _ apt-get -f install
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Correcting dependencies... Done
The following extra packages will be installed:
  libthunarx-2-0
The following NEW packages will be installed:
  libthunarx-2-0
0 upgraded, 1 newly installed, 0 to remove and 21 not upgraded.
Need to get 0 B/62.8 kB of archives.
After this operation, 284 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Selecting previously unselected package libthunarx-2-0.
(Reading database ... 194593 files and directories currently installed.)
Preparing to unpack .../libthunarx-2-0_1.6.3-2_amd64.deb ...
Unpacking libthunarx-2-0 (1.6.3-2) ...
Setting up libthunarx-2-0 (1.6.3-2) ...
Processing triggers for libc-bin (2.19-18+deb8u3) ...

and status of packages is:

dpkg -l | grep thunar
ri  bunsen-thunar                         8.0-1          
ii  libthunarx-2-0                        1.6.3-2             
rc  thunar                                1.6.3-2             
ii  thunar-data                           1.6.3-2             
rc  thunar-volman                         0.8.0-4

Running sudo apt-get install thunar again
re-installs thunar packages, except for bunsen-thunar

Running sudo apt-get install --reinstall bunsen-thunar gives

sudo apt-get install --reinstall  bunsen-thunar
Reading package lists... Done
Building dependency tree       
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 21 not upgraded.
Need to get 0 B/2,716 B of archives.
After this operation, 0 B of additional disk space will be used.
Selecting previously unselected package bunsen-thunar.
(Reading database ... 194674 files and directories currently installed.)
Preparing to unpack .../bunsen-thunar_8.0-1_all.deb ...
/var/lib/dpkg/info/bunsen-thunar.prerm: thunarx-2/thunar-wallpaperx-plugin.so not listed by libthunarx-2-0
dpkg: warning: subprocess old pre-removal script returned error exit status 1
dpkg: trying script from the new package instead ...
dpkg: ... it looks like that went OK
Unpacking bunsen-thunar (8.0-1) over (8.0-1) ...
Setting up bunsen-thunar (8.0-1) ...

-- Notice dpkg first runs the old prerm maintainer-script, which errors out again
-- But goes on to fork the new maintainer postinst script, which works OK.
-- and the packages are all restored to a consistent state.

With exit 0

I leave it up to the reader to repeat the tests, changing to exit 0 in

TL;DR
After running
sudo apt-get remove libthunarx-2-0
package bunsen-thunar is effectively removed, but
the bunsen-thunar diversion is still in place.
Which is an inconsistent state.

johnraff · 2016-03-24 01:50:35

@xaos thank you for taking the time to make all this clear.
Actually, I was aware of most of that myself, which is why the script does indeed exit 1 if the diverted file is not found in the output of 'dpkg -l'. The message:

/var/lib/dpkg/info/bunsen-thunar.prerm: thunarx-2/thunar-wallpaperx-plugin.so not listed by libthunarx-2-0

comes from bunsen-thunar's prerm script.

I was just imagining an extremely unlikely case that the script was no longer able to find 'thunarx-2/thunar-wallpaper-plugin.so'. (I've checked its location in Stretch and Sid also.) If that happened, the following code wouldn't know the path to the file it was trying to remove the diversion from, and I was wondering if it might be better in such cases to allow the removal of bunsen-thunar to proceed anyway.

Your tests showed that dpkg is very good at coping with this kind of messy situation, and exit 1 will be fine.

BTW it's quite possible to set a dpkg-divert on a non-existent file. This isn't necessarily an inconsistent state (I haven't tested all the behaviour when the diversion is set by a package which is no longer installed). If in the future some package ever installed that file, then the diversion would take place. That's why at first I didn't want to make bunsen-thunar dependent on libthunarx-2-0, so it needn't be uninstalled along with Thunar & co. However, we've found in all the preceeding discussion that adding that dependency is the easiest way to go.

tknomanzr · 2016-03-24 16:31:34

BTW it's quite possible to set a dpkg-divert on a non-existent file. This isn't necessarily an inconsistent state (I haven't tested all the behaviour when the diversion is set by a package which is no longer installed). If in the future some package ever installed that file, then the diversion would take place. That's why at first I didn't want to make bunsen-thunar dependent on libthunarx-2-0, so it needn't be uninstalled along with Thunar & co. However, we've found in all the preceeding discussion that adding that dependency is the easiest way to go.

This is interesting because my thinking is that if you have the diversion in place prior to installing thunar, then you wouldnt need to reinstall. I just hadnt figured out a way to make that happen without messing with thunar's dependency declarations OR setting it up in Live Build, neither of which is really an ideal solution.

johnraff · 2016-03-25 01:41:42

I've just confirmed that it's possible for a non-installed package to set a diversion. Here the non-existant bunsen-foo diverts thunar-archive-plugin.so :

john@bunsen:~$ sudo dpkg-divert --divert /usr/lib/i386-linux-gnu/thunarx-2/thunar-archive-plugin.so.bunsen-disabled --rename --package bunsen-foo --add /usr/lib/i386-linux-gnu/thunarx-2/thunar-archive-plugin.so
Adding 'diversion of /usr/lib/i386-linux-gnu/thunarx-2/thunar-archive-plugin.so to /usr/lib/i386-linux-gnu/thunarx-2/thunar-archive-plugin.so.bunsen-disabled by bunsen-foo'
john@bunsen:~$ ls /usr/lib/i386-linux-gnu/thunarx-2
thunar-apr.so
thunar-archive-plugin.so.bunsen-disabled
thunar-media-tags-plugin.so
thunar-sbr.so
thunar-uca.so
thunar-wallpaper-plugin.so.bunsen-disabled
john@bunsen:~$ dpkg-divert --list bunsen-foo
diversion of /usr/lib/i386-linux-gnu/thunarx-2/thunar-archive-plugin.so to /usr/lib/i386-linux-gnu/thunarx-2/thunar-archive-plugin.so.bunsen-disabled by bunsen-foo
john@bunsen:~$ dpkg-divert --list bunsen-thunar
diversion of /usr/lib/i386-linux-gnu/thunarx-2/thunar-wallpaper-plugin.so to /usr/lib/i386-linux-gnu/thunarx-2/thunar-wallpaper-plugin.so.bunsen-disabled by bunsen-thunar

If some other package than bunsen-foo tries to remove the diversion, dpkg rejects it.

@tknomanzr right, there's no need to reinstall packages with diverted files whether you set the diversion ahead of time or afterwards. The renaming of the diverted file takes place immediately, if it exists. If it doesn't yet exist, dpkg records the diversion and applies it when the file is installed.

Horizon_Brave · 2016-03-25 18:08:38

A few questions to anyone here... these may be silly... In John's example :

sudo dpkg-divert --divert /usr/lib/i386-linux-gnu/thunarx-2/thunar-archive-plugin.so.bunsen-disabled --rename --package bunsen-foo --add /usr/lib/i386-linux-gnu/thunarx-2/thunar-archive-plugin.so

You divert the binary /usr/lib/i386-linux-gnu/thunarx-2/thunar-archive-plugin.so to be sent to
/usr/lib/i386-linux-gnu/thunarx-2/thunar-archive-plugin.so.bunsen-disabled

So during install or upgrade of thunar, that plugin is sent to x.bunsen-disabled which is not used or referenced. So..

1. What happens if a user goes in and deletes the original thunar-archive-plugin.so? During an upgrade will this affect the diversion?

2. Can you create a diversion to /dev/null ? So instead of having a ton of 'fake' diverted files laying around, you can just divert them into nothingness?

3. Would it be wise to gather all diverted files on the system into one directory? I notice we use this diversion trick for a few other files as well, most noteably the lightdm.conf.

Thanks guys!

johnraff · 2016-03-26 00:32:30

1) After an upgrade or reinstall the file will still be renamed, as long as the diversion is in place.

2) I don't think so. Please try it and report your findings!

3) dpkg keeps a list of all diversions. 'dpkg-divert --list' to see it.

#21 2016-03-18 06:28:55

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#22 2016-03-19 02:14:08

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#23 2016-03-20 03:31:41

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#24 2016-03-20 09:39:46

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#25 2016-03-21 06:12:37

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#26 2016-03-21 10:20:09

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#27 2016-03-22 03:13:37

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#28 2016-03-22 12:50:59

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#29 2016-03-22 16:09:15

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#30 2016-03-22 16:26:39

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#31 2016-03-22 17:09:04

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#32 2016-03-23 02:11:15

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#33 2016-03-23 07:29:10

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#34 2016-03-23 08:12:14

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#35 2016-03-23 14:21:27

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#36 2016-03-24 01:50:35

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#37 2016-03-24 16:31:34

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#38 2016-03-25 01:41:42

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#39 2016-03-25 18:08:38

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

#40 2016-03-26 00:32:30

Re: Disable Thunar's unusable "Set as wallpaper" context menu item.

Board footer