package: debfoster severity: grave As requested in irc: The release goals for Squeeze have just been published [1]. One release goal is multiarch support, which, according to vorlon, in best case will already be in Ubuntu 9.10 (Feature freeze: August 27 [2]). The current multiarch spec [3] includes an extension to package relationship fields, e.g. "Depends: python:any". Such dependencies will lead to packages wrongly detected as orphaned by debfoster unless it ignores “:any”, which is the only one specified by now. I'm aware that deborphan suffers from the same issue and will upload a fixed package before Karmic's feature freeze. Feel free to file a bug against deborphan if you got too much time. Carsten [1] http://lists.debian.org/debian-devel-announce/2009/07/msg00001.html [2] https://wiki.ubuntu.com/KarmicReleaseSchedule [3] https://wiki.ubuntu.com/MultiarchSpec
* David Kalnischkies [2012-05-17 14:41 +0200]: Sorry for mixing this up. That changing it after the release in unreasonable is a good point. Given the unreasonableness of a change after Wheezy's release and that documenting possibly unintuitive behaviour in the BTS of a package with several hundred bugs is not that sane, I think this feature request should be closed during freeze, or, if it is clear that apt will not be changed previously, soonish. apt's command line tools do not provide a way to list the installed packages, so people using apt on the command line need to use for example dpkg to do so. synaptic users do not have this problem since it provides a complete user interface for the usual package management tasks, at least as long X as is not broken. If apt would provide a list sub-command, your explanation that this is not a bug in apt would be reasonable, nevertheless, this bug has severity wishlist, so it is indeed not a bug but a feature request ;) As a result of the inconsistency between apt's and dpkg's user interface, tools like debfoster (I CC'd the according 'please implement multiarch' bug) need to print package names with arch suffix on foreign architectures or its users will not always be able to remove the displayed packages using apt-get. It especially needs to pass the packages arch qualified to apt-get if it invokes it itself. If apt and dpkg would be consistent to each other, this behaviour could be documented in the policy so that other tools could rely on it, even in less widely used dpkg frontends. Your logic seems to be different to mine, anyway, you prefer the current behaviour over both alternatives and I prefer the current and my preferred behaviour over what you mentioned above, thus, at least unless someone else answers, removing the described convenience would all but reasonable. I agree to what you wrote, but what I understand under the above does not completely match the behaviour of apt-*, for example, on stable with unstable sources, apt-get source apt fails and there is no non-weird way to tell apt-get to do what it did in previous releases, except when you look up the version number previously. I would not ask apt-get to download its sources on a system with only unstable source entries in the sources.list if I did not want to get them. apt-cache show does not preserve the command line order in its output anymore. We already discussed installing essential packages automatically in the past. This explains a lot :) I always wondered why you are not listed in the uploaders field. Regards Carsten
I don't see the problem here. debian already has a commandline tool to list installed packages, as it has a tool to list the status of a package. Reimplementing that just to have it in a tool with the prefix "apt-" sounds wrong. That said, we have longstanding dreams about an apt-list command which can list all packages matching a certain criteria, but it isn't even started and in my case "longstanding" means at least two years already, so i wouldn't hold my breath to have it available soon… (criteria being something like autoinstalled [currently: apt-mark showauto], not downloadable anymore and such things dpkg obviously can't list). require a user to specify always the architecture if he deals with a M-A:same package. I dislike this because this changes overtime and isn't really easy to discover for a user. Yesterday libsame=1-1 installed fine, now i have to install libsame:native=1-2 to get what i want… (jftr: and the first in debian unreleased dpkg interface agreed with me) This would break debfoster (and many other scripts) way harder than the behavior now as the installation/removal of a library is a way more likely usecase and actually forces them to do a multiarch update, even through many script, howtos and even full-blown programs detailing how to install this and that will never really care about multi-arch (or at least they shouldn't). It also carries the problem that such a tool has to detect which version of APT it deals with (to know if it can/must use the architecture qualifier as e.g. squeeze includes already M-A:same packages). So, in short: You really don't want consistency between apt and dpkg. Maybe my concern for consistence inside apt-* is better understandable if you know that all apt-* tools nowadays share the same code to parse the commandline. Specifically the layer printing the 'Did you mean?' doesn't know what the user entered (in exchange, the code deciding about which package(s) the user talks doesn't know which action(s) will be performed). Maybe it is also because i regularly "remove" packages which are not installed in an install command as apt-get can be hinted this way that i don't want this package installed as a dependency of whatever i have requested. The inverse is also true if e.g. removing a bunch of packages by regex and just want to keep a few. (Not sure how many "normal" users know/use that through.) I agree that this is not always completely followed (hence the "usually"). Sometimes we really decide what we think might be best for the user and provide some crazy option-flag to work around it. APT would e.g. never download Translation files if we wouldn't try to detect a suitable default - for a few then quiet vocal users we get it wrong, but i can live with that if the general benefit is big enough. (aka: Exception proves the rule) I don't know your setup, but it sounds like you have APT::Default-Release set, so apt just does what you said. apt-get source apt/unstable might does the right thing™. That shouldn't have changed too much in squeeze through either, so feel free to add a few more details. That was fixed in the 0.9 release and is no longer true. (see 0.8.16~exp9 and #625960)
I didn't notice any actual report of debfoster behaviour with multiarch so far, so thought it might be useful (for maintainers, but mainly for querybtsers/googlers, to report it: fiori# arch x86_64 fiori# debfoster libcanberra-gtk-module is keeping the following 1 packages installed: libcanberra-gtk0 Keep libcanberra-gtk-module? [Ynpsiuqx?], [H]elp: P Keep gtk2-engines-pixbuf? [Ynpsiuqx?], [H]elp: P Keep libgail-common? [Ynpsiuqx?], [H]elp: P Keep libqt4-test? [Ynpsiuqx?], [H]elp: P Reading package lists... Done Building dependency tree Reading state information... Done Package 'gtk2-engines-pixbuf' is not installed, so not removed. Did you mean 'gtk2-engines-pixbuf:i386'? Package 'libgail-common' is not installed, so not removed. Did you mean 'libgail-common:i386'? Package 'libcanberra-gtk-module' is not installed, so not removed. Did you mean 'libcanberra-gtk-module:i386'? Package 'libcanberra-gtk0' is not installed, so not removed. Did you mean 'libcanberra-gtk0:i386'? Package 'libqt4-test' is not installed, so not removed. Did you mean 'libqt4-test:i386'? 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. fiori# COLUMNS=200 dpkg -l | grep libcanberra-gtk-module ii libcanberra-gtk-module:i386 0.28-6 i386 translates GTK+ widgets signals to event sounds fiori# HTH Alexis
Coin, It is sad nothing was done since 2009. Another type of error seen because of this lack of support: Keep libegl1-mesa-drivers? [Ynpsiuqx?], [H]elp: ? dpkg-query: error: --status needs a valid package name but 'libegl1-mesa-drivers' is not: ambiguous package name 'libegl1-mesa-drivers' with more than one installed instance Regards.
tag 539340 +patch
thanks
Here is a small patch for ignoring :any (and other arch specifications)
in the package names of dependencies. The correct solution would be to
track and compare the architecture in the pkg_version structure.
This should also fix #1001751 which I believe happenes because debfoster
ignores python3.10:any dependencies.
The second patch is a testcase. Although they don't seem to get run on
building the package.
Ingo
Hi Maintainers of debfoster, your package showed up as a candidate for the Bug of the Day[1] today and thus I had a look. The last maintainer upload was 10 years ago and there are a lot of bugs that are not answered by a maintainer. For proper maintenance of this native package I would propose moving the project to Salsa to enable some fruitful cooperation. IMHO the most natural location would be https://salsa.debian.org/debian/debfoster. However, since I'm not sure whether this is also your prefered choice (seems some debfoster team existed and you want to create your own team space) I simply created a temporary repostory just for your convenience in the Package Salvage team space[2]. I do not intend to keep it there if you want to continue maintaining debfoster but moving the repository to some other place is simply easier than if it would be in debian/. I would be delighted if you would give us some status update whether you intend to keep on with the development and maintenance (which would be really prefered). If you will not answer this mail in 21 days (the usual Intend to Salvage period) we might bring up this discussion again and decide inside the Package Salvage team what might be the best course of action. Kind regards Andreas. [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks [2] https://salsa.debian.org/salvage-team/debfoster/
Control: tags -1 patch help thanks IF I did an experimental upload including this patch, WOULD somebody other than me be willing to actually test this? I must admit that I only have multiarch in a handful of installations using wine on amd64, so my local tests would not be enough. Greetings Marc
Control: tags -1 patch help thanks IF I did an experimental upload including this patch, WOULD somebody other than me be willing to actually test this? I must admit that I only have multiarch in a handful of installations using wine on amd64, so my local tests would not be enough. Greetings Marc