Control: tags -1 + wontfix
On Wed, 17 Dec 2025 08:31:43 -0500 Andrew J. Buehler wrote: [...] > Dear Maintainer, > > This is a request for a feature addition which I would find helpful in > infrequent, but recurring, contexts. Hello Andrew, thanks for your feature request. To be honest, I've almost never encountered a scenario like the one you describe. But let's dive into more details... > > I occasionally run into a situation in which apt-listbugs shows a bug > against a particular package, but in order to enable apt to find a > dependency resolution which will permit carrying out other upgrades > without deciding to remove the affected package, it is necessary to pin > one or more other packages (either instead of, or in addition to, the > affected package) - ones which do not have the bug listed against them. That's awkward. As I said, I've almost never seen anything like this. It smells like a situation where at least one package has wrong or sub-optimal dependencies: maybe it's worth investigating whether some dependencies should be improved and file corresponding bug reports, so that the situation won't show up again in the future. > > Usually, though I think not always, this results from the bug having > been filed against - if not necessarily the *wrong* package - at least > not the most optimal choice from among the involved packages. In some of > those cases it would probably be most ideal to fix the problem by > reassigning the bug and/or changing the list of what packages it > affects; however, this is not always practical, e.g. for social / > political reasons. When the situation results from bug reports being assigned to wrong or sub-optimal packages, I really think that the best course of action is to reassign those bug reports. I know that sometimes social/political conflicts can complicate things a bit. But be polite, and explain the technical reasons behind the reassignment: in most cases, this will avoid or solve social/political conflicts. Above all, ask yourself: which package should be kept back from the upgrade in order to avoid introducing the bug into your system? That package is (almost) always the one against which a bug report should be filed or reassigned. Also, please note that there is the "affects" field in the Debian BTS. But apt-listbugs ignores this field. And it does so for a reason: please read the FAQ _Why does `apt-listbugs` ignore the "affects" field?_ in /usr/share/doc/apt-listbugs/FAQ.md.gz . You will see that the described scenarios have much in common with the ones you are talking about. And many considerations apply. > > I have occasionally tried to deal with this by manually pinning the > "correct" package (the one(s) which will enable dependency processing to > find an appropriate solution, without either hitting an > impossible-situation-requested deadlock or trying to remove the pinned > package in order to upgrade other packages). That typically works in the > short term, but not in the long term; if I pin the package using > apt-listbugs' interactive interface, apt-listbugs then detects "oh, this > package doesn't have this bug open against it" and removes the pin on > the next automatic check, and if I pin it entirely manually, I don't get > the benefit of apt-listbugs being able to detect when the bug has been > fixed. > > In cases where this happens, I would like to be able to use > apt-listbugs' interactive interface to say "pin package X because of bug > Y" - even when that bug does not have metadata showing that it has any > relation to that package - and see apt-listbugs first create the pin > entry in the preferences file, I see what you mean... > and then understand that "when this bug > is fixed, this pin can be removed", even though the bug is not formally > against the pinned package(s). ...but this last part is where the problem lies. How can apt-listbugs decide when the pin should be removed? Being "fixed" is not an all-or-nothing concept for a bug. A bug is fixed or not fixed in a given *version* of a package. What if the bug is fixed in Debian unstable, but you're tracking Debian testing? How can apt-listbugs know when your system is ready to see the pin removed, if the bug report is assigned to another package with version info about that other package? [...] > I cannot be absolutely positive that there is not already a way to do > this, but I have not managed to find one in the apt-listbugs UI or > documentation. I don't think there's a way to do this with apt-listbugs. But I think (for reasons similar to those explained in the FAQ about the "affects" field) that the best way to address these (infrequent) cases is to correct/improve the data in the Debian BTS. This also has the advantage to fix things for all users, rather than implementing a complicated strategy in apt-listbugs that would enable each user to work around incorrect/incomplete data in the BTS. I hope I explained myself clearly enough. Season's greetings! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpoF0HLwUN6W.pgp
Description: PGP signature
