Debian Bug report logs - #539340
debfoster: please add multiarch support

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Carsten Hey <carsten@debian.org>

To: bugs@debian.org

Subject: debfoster: please add multiarch support

Date: Thu, 30 Jul 2009 21:11:15 +0200

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

Message #10 received at 539340@bugs.debian.org (full text, mbox, reply):

From: Carsten Hey <carsten@debian.org>

To: 673193@bugs.debian.org

Cc: 539340@bugs.debian.org

Subject: Re: Bug#673193: apt-get: should remove foreign arch packages even if arch suffix is missing

Date: Fri, 18 May 2012 01:22:18 +0200

* David Kalnischkies [2012-05-17 14:41 +0200]:
> On Wed, May 16, 2012 at 10:16 PM, Carsten Hey <carsten@debian.org> wrote:
> > apt-get should remove foreign arch packages even if arch suffix is
> > missing.
> >
> > I know that you disagree, but documenting unintuitive behaviour in the
> > BTS in a good thing and this bug report explains why your reasoning is
> > wrong.
>
> In that sentence "you(r)" is /me, just so that everyone gets who is meant.

Sorry for mixing this up.


> (i think it is unreasonable to change it after wheezy release, but
> maintainer choice…)

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.


> No, dpkg is consistent in it's out-/input as is apt, so no bug.
> The out-/input just happens to be inconsistent between apt and dpkg.

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 ;)


> I could invoke the "i was first" argument here, but the "better" argument
> is that dpkg only needs to specify an architecture if a M-A:same package
> is involved (and in that case it forces it) while apt has to deal with all
> packages being either native or foreign at all times, so if multiple
> architectures for a package are available it needs to know which one
> the user talks about. For convenience native is assumed by default for
> all packages …

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.


> The logic consequence of this "bug" is through to remove the convenience
> of installing the foreign package in case no native package is available,
> not to add even more "maybe the user meant something else" logic…

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.


> It's up to frontends to guess what the user meant, apt-* usually does what
> the user said, even through the user might be wrong. I personally think that
> is better than trying to tell the program that i am not the idiot the program
> thinks i am and therefore decides to do something else instead.
> At least for a tools as low-level as apt-*.

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.


> P.S.: Yeap, this no maintainer thing is by choice and i like it.

This explains a lot :)  I always wondered why you are not listed in the
uploaders field.


Regards
Carsten

Message #15 received at 539340@bugs.debian.org (full text, mbox, reply):

From: David Kalnischkies <kalnischkies+debian@gmail.com>

To: Carsten Hey <carsten@debian.org>, 673193@bugs.debian.org, 539340@bugs.debian.org

Subject: Re: Bug#673193: apt-get: should remove foreign arch packages even if arch suffix is missing

Date: Fri, 18 May 2012 18:15:47 +0200

On Fri, May 18, 2012 at 1:22 AM, Carsten Hey <carsten@debian.org> wrote:
> * David Kalnischkies [2012-05-17 14:41 +0200]:
>> On Wed, May 16, 2012 at 10:16 PM, Carsten Hey <carsten@debian.org> wrote:
>> No, dpkg is consistent in it's out-/input as is apt, so no bug.
>> The out-/input just happens to be inconsistent between apt and dpkg.
>
> 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.

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).


>> I could invoke the "i was first" argument here, but the "better" argument
>> is that dpkg only needs to specify an architecture if a M-A:same package
>> is involved (and in that case it forces it) while apt has to deal with all
>> packages being either native or foreign at all times, so if multiple
>> architectures for a package are available it needs to know which one
>> the user talks about. For convenience native is assumed by default for
>> all packages …
>
> 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.

The problem with consistency is that in that case we would need to
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.)


>> It's up to frontends to guess what the user meant, apt-* usually does what
>> the user said, even through the user might be wrong. I personally think that
>> is better than trying to tell the program that i am not the idiot the program
>> thinks i am and therefore decides to do something else instead.
>> At least for a tools as low-level as apt-*.
>
> 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

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)


> 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.

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.


> apt-cache show does not
> preserve the command line order in its output anymore.

That was fixed in the 0.9 release and is no longer true.
(see 0.8.16~exp9 and #625960)


> We already
> discussed installing essential packages automatically in the past.

-o pkgCacheGen::Essential={all,native,installed,none}
native is the default. To have it really working you need to have it
in a config file through as it needs to be set at the time the binary
cache is generated. Documented in the bugreports alongside my general
warning that this is properly not a good idea.


Best regards

David Kalnischkies

P.S.: The devil in me just hopes we get co-installable binaries at some
point in debian. It will be so much fun to arch-qualify everything in dpkg.
(by hand i mean, APT already does this now as it was easier to implement)

Message #20 received at 539340@bugs.debian.org (full text, mbox, reply):

From: Alexis Huxley <alexishuxley@gmail.com>

To: Debian Bug Tracking System <539340@bugs.debian.org>

Subject: debfoster: bug confirmation

Date: Fri, 27 Sep 2013 09:21:27 +0200

Package: debfoster
Version: 2.7-1.2
Followup-For: Bug #539340

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 

-- System Information:
Debian Release: 7.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages debfoster depends on:
ii  libc6     2.13-38
ii  libgc1c2  1:7.1-9.1

Versions of packages debfoster recommends:
ii  apt  0.9.7.8

debfoster suggests no packages.

-- no debconf information

Message #25 received at 539340@bugs.debian.org (full text, mbox, reply):

From: Marc Dequènes (duck) <duck@duckcorp.org>

To: 539340@bugs.debian.org

Subject: Re: debfoster: please add multiarch support

Date: Sat, 17 Jan 2015 17:01:01 +0100

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.

-- 
Marc Dequènes

Send a report that this bug log contains spam.