The fact is that when upstream suggests to downgrade at-spi2, it is
difficult to know what should be downgraded. Basically we downgrade
at-spi2-core, and it should be enough (i.e. it should downgrade or make
user downgrade manually -common and libatspi2.0). Instead, we need to
search for all packages containing atspi string and guess that they are
all dependant and should be downgraded.
More generally, I guess that updating one package while the others are
not included in the process as not dependent may cause problems.
Regards
Jean-Philippe MENGUAL
Debian Developer non uploading
Accessibility team member
debian-l10n-french team member
President of Debian France non-profit organization
Le 22/08/2024 à 23:27, Samuel Thibault a écrit :
Jean-Philippe MENGUAL, le jeu. 22 août 2024 23:09:32 +0200, a ecrit:
Le 22/08/2024 à 23:03, Samuel Thibault a écrit :
Jean-Philippe MENGUAL, le jeu. 22 août 2024 22:51:15 +0200, a ecrit:
The problem mentioned here seems also to be mainly in another package:
libatspi2.0.
The libatspi2.0 binary package is part of the at-spi2-core source
package (which happens to also ship the at-spi2-core binary package)
SO why can I make them change version independently? If I downgrade
at-spi2-core, why dont I get a message requiring I also downgrade -common
and libatspi2.0?
Because there's no real strict dependency? Which actual issue do you
encounter?
Samuel
_______________________________________________
Pkg-a11y-devel mailing list
pkg-a11y-de...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-a11y-devel