[Desktop-packages] [Bug 1688721] Re: Packages that trigger multiple debconf prompts fail to install

2022-01-15 Thread invernosantigos
And just to embitter a bit, on Debian, there are complaints about this bug 
dating back 3 years...

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-software in Ubuntu.
https://bugs.launchpad.net/bugs/1688721

Title:
  Packages that trigger multiple debconf prompts fail to install

Status in gnome-software package in Ubuntu:
  Fix Released
Status in gnome-software source package in Xenial:
  Fix Released
Status in gnome-software source package in Yakkety:
  Fix Released
Status in gnome-software source package in Zesty:
  Fix Released
Status in gnome-software source package in Artful:
  Fix Released

Bug description:
  [Impact]
  Some packages stall on installing. These are packages that generate multiple 
debconf prompts (the prompts may be empty and so not user visible, e.g. 
gconf2-common).

  [Test Case]
  1. Remove gconf2-common (warning, may uninstall packages like gnome-terminal):
  $ sudo apt purge gconf2-common
  2. Download the debian package of Chrome from www.google.com/chrome.
  3. Install the package (browser will prompt, or double click on package in 
Nautilus).

  Expected result:
  Chrome installs correctly.

  Observed result:
  The installation hangs on 51%.

  [Regression Potential]
  The debconf conde was modified to support multiple requests. This could 
expose other debconf issues or break other .deb install code.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1688721/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1688721] Re: Packages that trigger multiple debconf prompts fail to install

2022-01-15 Thread invernosantigos
So far, the solution has been to apply
  sudo dpkg --configure -a
  sudo apt --fix-broken install
  sudo dpkg --configure -a

Which doesn't seem like something that will bring happiness to anyone.
 But the worst is that these solutions have not worked for everyone. A lot 
of people gave up and had to reinstall. I was left out, for example, and I was 
killing myself with this problem until I almost reincarnated. I'm sure when I 
die, I'll be canonized...


  I found ! I found the problem (and a better solution than what the veterans 
have recommended): Manually installing gconf2-common via dpkg -- which is 
normally considered dangerous and not recommended because of the risks. 
dconf2-common is definitely bugged, but it's not empty or false bug reports as 
some veterans and developers have said out there -- it's much more serious : 
The configuration is incomplete and errors go up to initramfs, which 
accumulates errors, until installation break. this accumulation even prevents 
the complete and correct installation of packages in the following updates, and 
these errors also go up to Initramfs, in a vicious circle that ends up breaking 
the installation. And the unfortunate gconf-service-backend and gconf-service 
have a circular dependency between them. In short, gconf is all shit by sheer 
sloppiness of the developer. A mistake is fine, but 2, including circular 
dependency is just plain sloppiness, really, indefensible! The difficulty here 
is "Dreadful" level. But I've had a lot of practice installing packages by 
hand, since the time of the legendary Build-Essential bug in Trusty Tahr, which 
broke the system every time you tried to install the damn thing, and took 2 
years to solve... challenge, and I had to download all the packages by hand and 
install them one-by-one, in order of dependencies, until I found the bugs. More 
than 20 depes... At the time, the bugs were, for example: a circular dependency 
on libc++-6-dev, and a dependency on it that was rotten and had to install the 
Lucid version, a brutal downgrade, 2 versions below. It was a school! I applied 
the same method here, although I don't miss the thing at all. The trick itself 
is to download the dependencies and place them in individual numbered folders, 
following the order they were installed in the dependency chain, and then open 
a terminal in each one and apply the dreaded "sudo dpkg --force-breaks -i *". 
This option is very dangerous, and it takes a lot of marijuana to face this 
adventure... So I first test with the "sudo dpkg -i *" version to see if there 
are any other pending dependencies. When approved, then yes, I reinstall with 
the option sudo dpkg --force-breaks -i * to ensure the package configuration 
without false or "semi-false" error warnings (which look fake, but generate 
errors in the initramfs ). The package gconf2-common can only be installed by 
this option in a folder ONLY with it. Otherwise, it is unconfigured, and it 
fucks all dependents of it that comes after... The option * should install all 
the packages that are in the folder together. But the new version of dpkg has 
one of those security features of dubious utility, which allows you to install 
a maximum of 3 depes together at once with this option (using the * replaces 
the package name -- instead of typing each name one- by one, with risk of 
error, we use *, in place of the name of the packages and dpkg installs all the 
dependencies that are in the folder ). Then you have to install 
gconf-service-backend and gconf-service TOGETHER in the same folder, folder 2, 
BECAUSE IT HAS CIRCULAR DEPENDENCE, and it is only possible to install circular 
dependency without breaking with "sudo dpkg --force-breaks - i *" and installed 
both together at the same time. Finally, in a third folder and with a third 
terminal, we install gconf2. If after all this installation you test with "sudo 
dpkg --configure -a" in a terminal, there is no response back, because there is 
no more configuration of pending files.

Well, that's all (Whew...) but the really bad thing is that you can't do it 
in a virtual machine, you have to risk your neck. Why ? Because this type of 
bug, like many others, tends not to happen with a fresh install, just a few 
updates after installing gconf2-commom bugs. If you install everything in one 
session, no problem, but after you update dpkg and restart the machine, the new 
version of dpkg -- much more error intolerant -- bugs gconf2-common... That's 
why I said it was the developer's unforgivable sloppiness: He wrote the package 
triggers for the system's native install dpkg version (the install CdRom) but 
not for the working version, the current version of dpkg. So, on the first 
update, it fucked up!

An eternal classic of this type of error, are the appimage packages, WHICH 
DOES NOT WORK IN LINUX MINT after some updates... They are simply not 
recognized as executables, no matter how