aptitude cannot handle conflicts with multiarch enabled

Worth mentioning in the known issues section of oneiric release notes?

After update to oneiric, aptitude gave me strange the option of removing 125 packages.
I had told it to forget the changes then search for broken packages, it picked up qdbus.
With synaptic I installed qdbus and removed qdbus:i386; Back to aptitude and the suggested removals are gone.

Now forget new packages resets after update and 6 unneeded (not recommended) packages get auto selected for install, guessing all down to this bug.

Definitely must be mentioned in the release notes. Better yet, a popup message on system upgrade when using aptitude.

I have the similar problem. After upgrading, aptitude tries to remove 123 packages from my system. I can ignore this by Actions - Cancel pending actions. Doing it, I can do normal operations on aptitude, and Search - Find Broken doesn't say anything. It is just normal, though the false alarm occurs again whenever aptitude is turned on.

Barosl, I recognized something similar after upgrading my notebook. After checking some of the packages I assumed that this may be some 32-bit libraries that are no longer necessary since aptitude said they are installed twice. So I made a backup of the system with rsync to an external hard drive, removed the packages and did a reboot to check if anything starts normal. There were no problems.

Dear all, same problem here. After oneiric upgrade, aptitude shows multiple duplicate entries, one of them being libc6. Both of these libc6 are marked as installed. When I mark one of the entries to be purged, it deletes about 1300 other packeages. When I try the other entry, about 475 packages are deleted.
Regards, Ruedi

Thanks everyone for confirming the bug. I don't think there's any more need to report it.

If you have any other useful information, please provide it.

Otherwise, please don't turn this bug report into a rant.

This is the first ubuntu release with multiarch enabled, so it's not that far-fetched that there will be problems with non-core tools (such as aptitude, as helpful as it might be).

Shahar, it's very likely that all of the multiarch bugs are due to the same problem, yes.

I mostly use aptitude for package managing. I use it daily.
Move /etc/dpkg/dpkg.cfg.d/multiarch to something else can disable multiarch.

#14 same for me, I'm really considering moving back to natty until this is fixed (also due to some other problems). So what would effect does that workaround have, and what are the side effects?

No need to move back to natty, if you can survive without 32 bit libraries on oneiric. Just comment out the single line in /etc/dpkg/dpkg.cfg.d/multiarch (as hinted in #14)

Personally I've decided I need aptitude more than I need multiarch.

What if I do need 32 bit libraries -- for example, my brother printer driver requires them. Is there a way to disable multiarch and just install 32 bit support manually?

Another example of why you might want 32-bit libraries is that I want to build wine with GL support, but when I try to install the libglu1-mesa-dev:i386 library (from xorg-edgers), apt-get wants to remove over 20 amd64 packages, and I'm not sure how badly it might break my system to go ahead.

AlexWinner: Rather than adding a comment saying it affect you, please click on the "This bug affects [...]" link at the top. It provides a meaningful metric, and reduces unnecessary clutter in the comments. Thanks.

@Max: Thank You for that fine solution! Finally I can use aptitude again.

In multiarchitecture enabled setup the command-line searches also fail to show installed packages correctly. The output of
aptitude search package-pattern
sometimes shows on installed packages that they are NOT installed. I guess that the conflict is in the same package of different architecture being not installed.

The not multiarch capable packages are not required by an multiarch package, but just recommended so just installing this particular package without recommends works.
For installing wine I used the following:

aptitude install --without-recommends libqt4-sql
aptitude install wine
aptitude markauto libqt4-sql:i386

Is this on track for precise?

I think this bug is fixed in the upstream repo (commit e823140847cff74fe97c0a95c727d1a0fe883750). Is there any chance this could be fixed in time for precise?

> Is this on track for precise? [April]

TL;DR: as far as upstream is concerned: yes and no. Some larger issues are resolved but unless more help is received there will be many annoyances remaining. Many of the problems are easy to fix but this requires hack-power (i.e. you). Ways in which someone could help:

- consider how commands such as "aptitude search foo" should behave (i.e. show all architectures, only native, foreign-if-installed, …)
- consider how the system in general should treat multiarch packages (consider them a single, or multiple packages? What are the pros and cons of each approach?)
- summarize the remaining multiarch *blockers* (these bug reports are noisy)

For advanced users/developers:
- use and test the current development version (note: git master branch)
- submit patches -- if making design choices (i.e. ignoring foreign-arch packages in CLI search) please explain these when submitting the patch

An upstream release in *Debian* will likely arrive happen during March.

The details…

> I think this bug is fixed in the upstream repo (commit
> e823140847cff74fe97c0a95c727d1a0fe883750)

tbjablin has correctly identified a commit which should have resolved most of the issues involving package states (e.g., being repeatedly considered new, or wrongly installed/not installed). Other recent changes have further improve the general situation but there are still many outstanding problems.

**The current changes are intended only as a stop-gap**

The intention here is to alleviate the problems that many users are experiencing with aptitude on multiarch systems. This may be suitable for release, however, some aspects will likely change in the future. Basically this is the quickest possible way to make the program usable.

**These changes should not yet be considered as "support" for multiarch in aptitude**

To summarise the recent changes:

- foreign-arch packages are arch-qualified ("pkgname:arch") in most places (ala apt-get)
- package states are remembered distinctly for each package:arch combination
- search terms ?architecture and ?multiarch

so, for example, when resolving dependency problems you will now clearly see the architecture of the packages involved and be more informed about what is going on.

The most significant remaining issue is that the dependency/problem resolver has no specific multiarch awareness. This manifests not only in visible garbage[2] but also means that the resolver can not be considered reliable on multiarch systems, in particular, it may or may not act according to the multiarch specification.

The way that APT has implemented multiarch support mitigates this to some extent and the resolver *appears* usable in in some situations (now that architectures are exposed to the user). This is a testament to the great design of those changes in APT. However, I must repeat: the aptitude dependency resolver in it's current (upstream development) form can not be considered correct for multiarch systems.

[2] http://bugs.debian.org/651748

Some command-line actions behave poorly:

$ aptitude search ^emacs23
p emacs23:amd64 - The GNU Emacs editor (with GTK+ user inter
p em...

Hello,

thanks for bringing these fixes.

From my view these are probably enough to make aptitude "support multiarch".

As for resolver being unreliable on multiarch - I don't consider that
a multiarch issue.

It is a long-standing problem that the resolver is generally
unreliable. Any possible multiarch-specific issues will be lost in the
heaps of issues the resolver already has.

The value I see in aptitude is an interactive UI for exploring
packages and their dependencies which should be restored once aptitude
can deal with packages of multiple architectures sanely.

Some suggestions:
* aptitude search should show results from all architectures. For filtering of search results by architecture, a new search term should be made (list of serach terms(1))," ?architecture". Short form "~r". Examples: "?architecture(amd64)" and "~ramd64".
 It should show results from all architectures because aptitude's search behavior(2) is very simple: if a package matches all of the terms, it matches the search pattern. So treating the architecture as another search term leverages aptitude's searching mechanism to allow for flexible searching by architecture and also conforms with the expected behavior of aptitude's search.

* Generally, the system should treat multiarch packages as single packages. Mainly because they are. Multiarch packages should have a pseudo-architecture, "all". For example, "apache2-doc:all". This will conform to the filename policy, e.g: "apache2-doc_2.2.22-1ubuntu1_all.deb". This will allow easy and obvious searching in aptitude. For example, "aptitude search ~napache2" would provide all architectures and to filter by architecture One would go, for example, "aptitude search ~napache2~ramd64".
 Treating the multiarch packages as if they were multiple packages would cause confusion. I wouldn't want to even go in to that.

* Aptitude should always default to installing the native architecture when no architecture is specified. This is obvious.

When displaying package names, aptitude should always print their architecture as well, in the format "<name>:<architecture>".

Perhaps there can be a switch in Aptitude that hides packages of foreign architectures when the same name packages exist for the local architecture. With this switch on, Aptitude can also hide the ":<architecture>" part of the names of packages of the local architecture and only display this part for packages of foreign architectures. This would make Aptitude less cluttered. But I would advise against this switch because it could be utterly confusing. Users of Aptitude should be advanced enough to use it's flexible search and interactive mode filtering to display whatever packages / architectures they wish to see.

If multi-arch is disabled system-wide, then Aptitude should still display the full "<name>:<architecture>" format because there may still be foreign architecture packages installed.

There should be a switch in Aptitdue to disable display of the ":<architecture>" part of the format.

1. http://algebraicthunk.net/~dburrows/projects/aptitude/doc/en/ch02s03s05.html
2. http://algebraicthunk.net/~dburrows/projects/aptitude/doc/en/ch02s03.html

Thanks for the suggestions.

> [add search term "?architecture(amd64)", "~ramd64"]

This is done (development version). Also there is
'?multiarch(foreign)' etc.

'~r' is a reasonable choice for the short form. I had not
previously assigned one but will do.

> It should show results from all architectures because aptitude's
> search behavior(2) is very simple: if a package matches all of the
> terms, it matches the search pattern.

While this is "technically correct" behaviour, I wonder about it's
utility /on the command-line/. In particular, if a user has
lots of architectures configured (for cross-building or something)
then they will receive many duplicate results:

$ aptitude search pkfoo
i pkfoo
p pkfoo:armel
c pkfoo:mips
p pkfoo:mipsel
…

I have thought that the generic search (as above, without any
'?terms') should, by default, only return packages for the native arch
*and* any foreign-arch packages that are in some non-trivial state
(installed, config-files, etc.). For most packages, they are
available on every configured arch and the user is implicitly aware of
this. Listing each when they are in the not-present state is just
noise.

If a package is not available on the native arch then the first
foreign-arch version of it will be shown:

$ aptitude search only-for-mips
p only-for-mips:mips

If the user includes an '?archicture(..)' term (or perhaps any term?)
then that would override this behaviour.

Effectively, a search pattern without any '?architecture(..)' term
includes an implicit '?architecture(native-or-next-available)'.

> * Generally, the system should treat multiarch packages as single
> packages. Mainly because they are.

There are subtle differences.

For instance, dependencies vary. Binary packages for hurd-i386, for
example, depend on libc0.3; on freebsd-any they depend on libc0.1;
most other architectures will depend on libc6 *but* the version
required does vary, depending on the architecture.

I am not sure specifically what you mean by "treat multiarch packages
as single packages". Do you mean that, e.g., the interactive mode
of the program should only show each package once? This is possible,
by showing dependencies with arch-qualifiers ala packages.d.o:

  libc0.3 (>= 2.4) [hurd-i386]

There is further complication, that packages may not be updated in
lockstep (i.e. hurd-i386 has version 1.0 while amd64 has 2.0). Then
which should be considered the candidate version for installation?

This *could* be a configurable option, even the default behaviour.
However, it requires larger changes than simply having multi-arch
packages separated by architecture and so I will not be working on
this immediately.

> Multiarch packages should have a pseudo-architecture, "all".

Hi, what?

There is already Architecture: all. I don't understand what you
mean here. Multi-arch packages are of whatever architecture they
are for.

> Treating the multiarch packages as if they were multiple packages
> would cause confusion. I wouldn't want to even go in to that.

Disagree with you here, but then I'm not 100% sure what you meant in
the last two parts so need some clarification.

> * Aptitude should always d...

Hi Michal (hramrach)

> Any possible multiarch-specific issues will be lost in the
> heaps of issues the resolver already has.
>

Some do stand out quite harshly. Consider #651748 [1] where the UI
is trashed by multi-arch related error messages from the resolver.
This is non-fatal but still a serious blocker.

I have not encountered it since some recent changes, however,
neither have I conducted an analysis to determine whether or not
it is actually resolved.

[1] http://bugs.debian.org/651748

> The value I see in aptitude is an interactive UI for exploring
> packages and their dependencies which should be restored once aptitude
> can deal with packages of multiple architectures sanely.
>

Then you should be pleased with the changes made thus far :-)

How to get problems like this added to the Known issues in Release Notes:

I think the biggest crime here is that this has not been added to the Oneric release notes in the last 6 months.

(I HAVE contacted the appropriate person and have been told it will be added on Monday.)

Go to https://wiki.ubuntu.com/ReleaseTeam
Notify the Release Manager of what needs to be added to the Known issues. (Again, I've done this for this bug on Oneric and Precise.)

I really wish I didn't upgrade last night.

Workaround:

After trying the previously mentioned workaround, things were still broken, complaining about qdbus. So I did:

# If you have disabled multiarch by modifying /etc/dpkg/dpkg.cfg.d/multiarch, you must re-enable it temporarily. The file should exist, and contain the line "foreign-architecture i386" (on my amd64 machine at least).
apt-get update
apt-get install qdbus # will remove qdbus:i386 and install qdbus
# Disable /etc/dpkg/dpkg.cfg.d/multiarch again - add a "#" at the beginning of the line it contains.
aptitude update
aptitude -f install # finally clean
aptitude dist-upgrade # also happy again

So this bug only affects people using 64 bit installs?

I'd still like a better understanding of what my options are if I need to install 64 bit software.

I decided I don't need aptitude anymore. Thought this info might be useful for others here. Of course, aptitude should still be fixed.

I only used aptitude because I knew if I installed a package, and it automatically installed dependencies, then I uninstalled that package, it would also uninstall its dependencies. When I started using aptitude, apt-get couldn't do that. I basically never use the ncurses interface of aptitude anymore.

It turns out that "apt-get remove" provides that same functionality of removing automatically installed dependencies. Both dependencies that were installed via aptitude, and apt-get. Handling of dependencies installed by aptitude was addded "~4 years ago... when apt started having a notion of autoinstalled packages". - #ubuntu-devel

The devel channel also said that autoremove also works for dependencies installed by all the gui package management software: software-center, update-manager, and synaptic, because they use libapt. So I can stop avoiding using those, which is nice.

You need to use "autoremove" instead of "remove" because apparently somebody thought that was bad default behavior. I'd like something shorter to type than "autoremove".

And, as I guess has been mentioned earlier in this bug, the aptitude resolver is kind of icky.

Here's the evidence autoremove works:

# lsb_release -c
Codename: oneiric

# aptitude install clisp
The following NEW packages will be installed:
  clisp libffcall1{a}
0 packages upgraded, 2 newly installed, 0 to remove and 0 not upgraded.

# apt-get autoremove clisp
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  clisp libffcall1
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.

# apt-get install clisp
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  libffcall1
Suggested packages:
  clisp-doc clisp-dev slime
The following NEW packages will be installed:
  clisp libffcall1
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.

# apt-get autoremove clisp
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  clisp libffcall1
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.

On 10 March 2012 05:49, Daniel Hartwig <email address hidden> wrote:
> Hi Michal (hramrach)
>
>> Any possible multiarch-specific issues will be lost in the
>> heaps of issues the resolver already has.
>>
>
> Some do stand out quite harshly.  Consider #651748 [1] where the UI
> is trashed by multi-arch related error messages from the resolver.
> This is non-fatal but still a serious blocker.

Is this multiarch specific?

IIRC I got this noise way before multiarch, there was just way less
noise before there were packages aptitude does not understand.

Now that aptitude understands multiarch packages you should not get
bazillions of errors.

Sure, it's still potential problem that there is no rate limit on
these messages or anything but it's no longer likely that you will not
see any UI at all due to messages rolling all over your screens
constantly.

>> Some do stand out quite harshly. Consider #651748 [1] where the UI
>> is trashed by multi-arch related error messages from the resolver.
>> This is non-fatal but still a serious blocker.
>
> Is this multiarch specific?
>
> IIRC I got this noise way before multiarch, there was just way less
> noise before there were packages aptitude does not understand.
>

Indeed. Before m-a the messages were very infrequent, one could
consider this a less than serious issue.

After m-a such messages are now frequently encountered when
performing any non-trivial action.

Getting noticeably more garbage on the screen is a problem.

> Now that aptitude understands multiarch packages you should not get
> bazillions of errors.
>

Have you been using the in-development version and noticed less
errors, or is this just speculation?

If you have been using that version, then this is useful information.
Obviously I can know what is happening on my system which is only
a small m-a chroot for the moment--not the most extensive
test setup.

> Sure, it's still potential problem that there is no rate limit on
> these messages or anything but it's no longer likely that you will not
> see any UI at all due to messages rolling all over your screens
> constantly.
>

[The standard C-l works in aptitude to refresh the screen.]

The underlying problem is that these internal debug messages
should not be dumped to stdout while using the curses interface.
They should either direct to a file by default or be captured
using apt-pkg/contrib/error.h like other error messages.

>> Now that aptitude understands multiarch packages you should not get
>> bazillions of errors.
>>
>
> Have you been using the in-development version and noticed less
> errors, or is this just speculation?

No, I don't see the in-development version packaged anywhere. However,
this is more than just speculation. Obviously, many of the errors are
caused by aptitude's inability to tell apart package:i386 and
package:amd64 which should by fixed now.

On 10 March 2012 06:20, Daniel Hartwig <email address hidden> wrote:
> '~r' is a reasonable choice for the short form.  I had not
> previously assigned one but will do.

Great!

>>  It should show results from all architectures because aptitude's
>> search behavior(2) is very simple: if a package matches all of the
>> terms, it matches the search pattern.
>
> While this is "technically correct" behaviour, I wonder about it's
> utility /on the command-line/.  In particular, if a user has
> lots of architectures configured (for cross-building or something)
> then they will receive many duplicate results:
>
> $ aptitude search pkfoo
> i   pkfoo
> p   pkfoo:armel
> c   pkfoo:mips
> p   pkfoo:mipsel
> …
>
> I have thought that the generic search (as above, without any
> '?terms') should, by default, only return packages for the native arch
> *and* any foreign-arch packages that are in some non-trivial state
> (installed, config-files, etc.).  For most packages, they are
> available on every configured arch and the user is implicitly aware of
> this.  Listing each when they are in the not-present state is just
> noise.
>
> If a package is not available on the native arch then the first
> foreign-arch version of it will be shown:
>
> $ aptitude search only-for-mips
> p   only-for-mips:mips
>
> If the user includes an '?archicture(..)' term (or perhaps any term?)
> then that would override this behaviour.
>
> Effectively, a search pattern without any '?architecture(..)' term
> includes an implicit '?architecture(native-or-next-available)'.

We do want to make the search results as humanly readable as possible
while keeping it obvious to understand.

We should do this by assuming that most users prefer native
architectures and would like to see what's installed, has
configuration files or is broken (these three are the non-trivial
states, right?).

So an aptitude search without ?terms() should print:
1. packages that are available in the native architecture as "<name>"
2. multi-arch packages as "<name>:all"
3. each available architecture of packages that are available only in
foreign architectures as "<name>:<architecture>"
4. foreign architecture packages that are in non-trivial states as
"<name>:<architecture>"

This should be called "?architecture(prefer-native)".

So the difference between this and the
"?architecture(native-or-next-available)" term value is that it would
show all architecture packages and not only the first foreign
architecture package. The reason for this is that the order in which
they are specified in the /etc/dpkg/dpkg.conf.d/multiarch is not an
order of preference.

# so for example
$ dpkg --print-architecture
amd64
$ aptitude search foo
p foobar # no architecture suffix because native
p foo-common:all # multi-arch
p foo-mips:mips # only in foreign architectures...
p foo-mips:mipsel # so printing all of them
p food # same as foobar
i food:i386 # installed and foreign
c food:mips # configuration files present and foreign

This defaulting to an "?architecture(prefer-native)" filter in
command-line search is a preference of convenience over consistency.
To prevent any trouble, whenever a search ...

> 3. each available architecture of packages that are available only in
> foreign architectures as "<name>:<architecture>"

Ok, this may prove more useful than what I was considering (only show the first such architecture).

> The reason for this is that the order in which
> they are specified in the /etc/dpkg/dpkg.conf.d/multiarch is not an
> order of preference.

Dpkg does not care about the order of architectures because it only deals with exactly the packages it is instructed to.

On the APT level a prefered order is needed. APT::Architectures is the configuration item that defines this (/etc/apt/apt.conf or /etc/apt/apt.conf.d/*).

> Dear Daniel, you said "- consider how the system in general should
> treat multiarch packages (consider them a single, or multiple
> packages? What are the pros and cons of each approach?)"
>
> Can you please elaborate on that question?

Things like, should the package view be grouped by architecture?

--\ Installed Packages
  --\ armel
    --- admin
    ...
  --\ powerpc
    --- admin
    ...

Or should each package only be shown once (just the name) and
have the different available architectures elaborated on the
package info screen?

> Why should multi-arch
> packages be considered multiple packages?

To be clear, when I say 'multi-arch packages' I am refering to packages which implement the multi-arch spec[2] -- not packages which are 'Architecture: all'. I am not sure if you mean the same thing here, since you keep refering to multi-arch packages being displayed as "pkg:all".

The reason they might be considered separate packages is because they are. Anything else is just a (potential) convenience to the user.

foo:armel, foo:powerpc, foo:amd64 are all distinct packages which just happen to share the same name. There are many differences between them that make each unique.

[2] http://wiki.ubuntu.com/MultiarchSpec

>>> Treating the multiarch packages as if they were multiple packages
>>> would cause confusion. I wouldn't want to even go in to that.
>>
>> Disagree with you here, but then I'm not 100% sure what you meant in
>> the last two parts so need some clarification.
>
> I'm also not 100% sure what you meant with that, above.

I meant that I was confused about the last two parts of your post because it seemed like you were refering to "multi-arch packages" as being equivalent to "architecture: all".

The part I disagree with is that treating multi-arch packages as multiple packages would cause confusion.

>> I consider it undesirable for aptitude to deviate from APT on this
>> point. However, having this configurable (e.g. "APT::FullName::Pretty-Print")
>> would be an excellent option.
>
> Yes, this is an excellent idea. As long as Architecture:all packages
> are printed with the ":all" suffix, to differentiate them from the
> native arch packages.
>

"apache-doc:all" would be deviating from APT, which shows "apache-doc".

Also, 'Architecture: all' is always a native architecture.

On 13 March 2012 03:26, Daniel Hartwig <email address hidden> wrote:
>> 3. each available architecture of packages that are available only in
>> foreign architectures as "<name>:<architecture>"
>
> Ok, this may prove more useful than what I was considering (only show
> the first such architecture).
>
>> The reason for this is that the order in which
>> they are specified in the /etc/dpkg/dpkg.conf.d/multiarch is not an
>> order of preference.
>
> Dpkg does not care about the order of architectures because it only
> deals with exactly the packages it is instructed to.
>
> On the APT level a prefered order is needed.  APT::Architectures is the
> configuration item that defines this (/etc/apt/apt.conf or
> /etc/apt/apt.conf.d/*).
>
>> Dear Daniel, you said "- consider how the system in general should
>> treat multiarch packages (consider them a single, or multiple
>> packages? What are the pros and cons of each approach?)"
>>
>> Can you please elaborate on that question?
>
> Things like, should the package view be grouped by architecture?
>
> --\ Installed Packages
>  --\ armel
>    --- admin
>    ...
>  --\ powerpc
>    --- admin
>    ...
>
> Or should each package only be shown once (just the name) and
> have the different available architectures elaborated on the
> package info screen?

The problem with showing separate archs separately is there is no easy
way to list the packages then.
In the ideal case they are at least in the same section (but may not
if the section was changed and not all archs are rebuilt) but still
some might be under new, another under installed, another under
uninstalled, ..

Showing the packages for different archs should be easier than
searching all sections.

Sure, you can change the way Aptitude organizes packages but there is
no good UI for that. You have to manually type in the properties by
which the packages should be categorized.

On 13 March 2012 04:26, Daniel Hartwig <email address hidden> wrote:
>> 3. each available architecture of packages that are available only in
>> foreign architectures as "<name>:<architecture>"
>
> Ok, this may prove more useful than what I was considering (only show
> the first such architecture).
>
>> The reason for this is that the order in which
>> they are specified in the /etc/dpkg/dpkg.conf.d/multiarch is not an
>> order of preference.
>
> Dpkg does not care about the order of architectures because it only
> deals with exactly the packages it is instructed to.

Thanks, Got it.

> On the APT level a prefered order is needed.  APT::Architectures is the
> configuration item that defines this (/etc/apt/apt.conf or
> /etc/apt/apt.conf.d/*).

Thank you!

>> Dear Daniel, you said "- consider how the system in general should
>> treat multiarch packages (consider them a single, or multiple
>> packages? What are the pros and cons of each approach?)"
>>
>> Can you please elaborate on that question?
>
> Things like, should the package view be grouped by architecture?
>
> --\ Installed Packages
>  --\ armel
>    --- admin
>    ...
>  --\ powerpc
>    --- admin
>    ...
>
> Or should each package only be shown once (just the name) and
> have the different available architectures elaborated on the
> package info screen?

Packages from different architectures should definitely be displayed
as individual packages because:
1. They are individual packages. Unlike different package versions,
these can be installed simultaneously. That's the difference.
2. Would be far better to not have to go into the package detail
screen to see available architectures. This is more practical, more
productive, etc. . I can imagine it being a nightmare to have to go
into package details to see about the availability of architectures
and in the worst case when a dependency issue (as soon as the resolver
is able to do that) arises. Rather, they should be listed with the
"<name>:<architecture>" format because that would promote the mental
sanity of our users. Of course, there's the
"?architecture(prefer-native)" that we talked about, which can be used
to make the lists even more sane and that it should be in the default
view. Of course, this argument can be individual so while I suspect
that I speak for most users of Aptitude curses interface, it would be
nice to have another opinion.
3. This is to be consistent with the results in the command-line
"aptitude search". It can't be reasonable to display multiple
architectures one way on the command line search and another on the
curses interface, can it?

>> Why should multi-arch
>> packages be considered multiple packages?
>
> To be clear, when I say 'multi-arch packages' I am refering to packages
> which implement the multi-arch spec[2] -- not packages which are
> 'Architecture: all'.  I am not sure if you mean the same thing here,
> since you keep refering to multi-arch packages being displayed as
> "pkg:all".

Yes, I apologize. You understood my mistake, calling "Architecture:
all" packages "multi-arch" packages. We can call them neutral
architecture packages :) . It may catch on.

>> Yes, this is an excellent idea. As...

> Packages from different architectures should definitely be displayed
> as individual packages because:
> ...

That was my reasoning also. This is much easier to implement and
practically already done.

> What if I care? What if I want to see, in a search result or a
> filtered view, both native and neutral architecture packages and to be
> able to tell them apart from each other? Treating the neutral ones as
> if they were native ones should be a deault - like
> ?architecture(prefer-native) is - not a constraint.

Configuration item to always show the ':<arch>' bit. When enabled you
will have both ':NATIVE' and ':all' displayed.

Ideally, such an option will be implemented in APT and so also
respected by apt-get and others.

On 13 March 2012 18:18, Daniel Hartwig <email address hidden> wrote:
>> Packages from different architectures should definitely be displayed
>> as individual packages because:
>> ...
>
> That was my reasoning also.  This is much easier to implement and
> practically already done.

Woohoo!

>> What if I care? What if I want to see, in a search result or a
>> filtered view, both native and neutral architecture packages and to be
>> able to tell them apart from each other? Treating the neutral ones as
>> if they were native ones should be a deault - like
>> ?architecture(prefer-native) is - not a constraint.
>
> Configuration item to always show the ':<arch>' bit.  When enabled you
> will have both ':NATIVE' and ':all' displayed.
>
> Ideally, such an option will be implemented in APT and so also
> respected by apt-get and others.

Sure, I'll file a request against APT.

What exactly do we want? I'm not familiar with APT configurations.

> Sure, I'll file a request against APT.

Never mind that. I will have a patch ready shortly.

On 13 March 2012 21:18, Daniel Hartwig <email address hidden> wrote:
>> Sure, I'll file a request against APT.
>
> Never mind that.  I will have a patch ready shortly.

Thank you very much, Daniel!

remove unneeded Baltix task

I had multiarch disabled for this bug. I just came across a new bug that forced me to re-enable it: Bug #963151.

The new upstream version of aptitude, 0.6.6, has just been released and should solve this.

I see aptitude v0.6.6 isn't in the Precise archive yet:
http://packages.ubuntu.com/search?keywords=aptitude

Is it going to make the precise release?

Dear Friends,

Perhaps someone who is monitoring Aptitude's bugs[1] would step in to report on implications of uploading 0.6.6 to precise?

Can someone please package 0.6.6 for precise in order to promote the freeze exception?

   1. http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=aptitude;dist=unstable

I tried to install aptitude_0.6.6-1_amd64.deb from debian/unstable today on Precise, but that doesn't work because of a missing dependency to libapt-pkg4.10, which is provided by apt 0.8.15.10 in Debian, but installing that would be a downgrade from the Precise apt 0.8.16~exp12ubuntu6. So I gave up. :(

On Mar 29, 2012 6:16 PM, "Stephan Springer" <email address hidden> wrote:
>
> I tried to install aptitude_0.6.6-1_amd64.deb from debian/unstable today
> on Precise, but that doesn't work because of a missing dependency to
> libapt-pkg4.10, which is provided by apt 0.8.15.10 in Debian, but
> installing that would be a downgrade from the Precise apt
> 0.8.16~exp12ubuntu6. So I gave up. :(
Thanks. Freeze exceptions require thorough QA, so we really need a package
built.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/831768
>
> Title:
> aptitude cannot handle conflicts with multiarch enabled
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/aptitude/+bug/831768/+subscriptions

I managed to rebuild aptitude 0.6.6-1 (from debian unstable). This also required rebuilding libgtest-dev and google-mock from debian unstable. Once installed, I can confirm that this is definitely an improvement: i386 packages are labelled as package:i386. aptitude still wants to remove all the :i386 packages whenever there is any sort of conflict.

Scratch the part about the conflict, it was justified in this case :)

Thanks for your effort. Could you please upload this to a PPA so that others can try it out, too?

I hope this can still make it into Precise, because it should fix a lot of bugs.

I'm uploading 0.6.6-1ubuntu1 to precise now. However, I'm not closing this bug at this point, because I'm not convinced it entirely fixes it (and upstream doesn't appear to truly claim that it does). The directions in the bug description still produce a certain degree of chaos; Daniel, do you think you could try those out? They're quite easy to follow in a precise amd64 chroot, such as one created using mk-sbuild in precise. I don't normally use aptitude myself (although I did at least make sure that my upload seemed to still work for non-multiarch cases), so I don't really consider myself qualified to say whether this is usable for multiarch yet.

However, this is clearly closer to a solution, and I expect that uploading this will reduce noise and make it easier to see what remains to be done.

Wow! Nice! Having Aptitude working again is like bringing control into my hands over package management again. I almost forgot how much I missed it!

And from my playing around with it, it is able to resolve with multi-arch quite nicely! I haven't found any bugs with that.

But I haven't tried the reproduction steps in the description.

Thanks and Blessings,
Shahar

I haven’t tried the new resolver yet, but the display of :arch qualifiers on foreign packages is a massive improvement.

It’s still missing in a few places though, like the “Provided by” line for virtual packages:

$ aptitude show ia32-libs-multiarch
No current or candidate version found for ia32-libs-multiarch
Package: ia32-libs-multiarch
State: not a real package
Provided by: ia32-libs-multiarch

And packages are listed twice in Conflicts/Breaks/Replaces without :arch qualifiers:

$ aptitude show wine1.4
…
Conflicts: wine1.0, wine1.0, wine1.4
Breaks: ttf-symbol-replacement, ttf-symbol-replacement,
        ttf-symbol-replacement-wine1.3, ttf-symbol-replacement-wine1.3,
        ttf-tahoma-replacement (< 1.3), ttf-tahoma-replacement (< 1.3), wine (<
        1.2.1), wine (< 1.2.1), wine1.2 (< 1.4-0ubuntu1), wine1.2 (<
        1.4-0ubuntu1), wine1.3 (< 1.4-0ubuntu1), wine1.3 (< 1.4-0ubuntu1)
Replaces: ttf-symbol-replacement, ttf-symbol-replacement,
          ttf-symbol-replacement-wine1.3, ttf-symbol-replacement-wine1.3,
          ttf-tahoma-replacement, ttf-tahoma-replacement, wine, wine, wine1.0,
          wine1.0, wine1.2, wine1.2, wine1.3, wine1.3

Same thing in the GUI:

i A --\ wine1.4 1.4-0ubuntu1 1.4-0ubuntu4
…
  --\ Replaces (14)
    --- ttf-symbol-replacement
    --- ttf-symbol-replacement
    --- ttf-symbol-replacement-wine1.3
    --- ttf-symbol-replacement-wine1.3
    --- ttf-tahoma-replacement
    --- ttf-tahoma-replacement
    --\ wine
i 1.4-0ubuntu4
p wine:i386 1.4-0ubuntu3
i A wine1.4 1.4-0ubuntu1
p A wine1.4 1.4-0ubuntu4
    --\ wine
i wine 1.4-0ubuntu4
p wine:i386 1.4-0ubuntu3
p wine1.4:i386 1.4-0ubuntu3
    --- wine1.0
    --- wine1.0
    --- wine1.2
    --- wine1.2
    --- wine1.3
    --- wine1.3

While the situation has definitely improved as you can now install multiarch packages from aptitude, the depenceny resolver is still a mess. Attached is a log with a few packages having unresolved dependencies because they're from a work-in-progress archive. The full resolver gives many internal errors and ends with removing over 200 packages, aptitude safe-upgrade doesn't do anything but simply aborts as it can't resolve the dependencies.

apt-get upgrade simply holds 8 packages back and upgrades the rest. dist-upgrade holds 7 back and wants to remove a few which is still reasonable.

Well, the resolver is a mess.

That's regardless of multiarch.

That's a bunch of separate issues.

Maybe it does work worse on multiarch but it works poorly under any conditions so it's hard to tell.

Dear Anders, Philip, Michal, Friends,

I've filed individual bugs for the two issues that you mentioned, Anders.

Is there a "Well, the resolver is a mess." bug report :) ? Really, is there? Launchpad or upstream Debian? Please give pointers if you have them.

Thanks and Blessings,
Shahar

Oh, here they are:
Bug #972858 and Bug #972847.

On 3 April 2012 23:12, Shahar Or <email address hidden> wrote:
> Dear Anders, Philip, Michal, Friends,
>
> I've filed individual bugs for the two issues that you mentioned,
> Anders.
>
> Is there a "Well, the resolver is a mess." bug report :) ? Really, is
> there? Launchpad or upstream Debian? Please give pointers if you have

There is plenty of resolver issues reported in the Debian BTS.

#432017 #346321 #391377 #495711 #502285 #519893 #570377 #579071
#588665 #594237 #619575 #632125 #637257 #651947 #659341 #186481
#209414 #213263 #248443 #251915 #252264 #325160 #330503 #333546
#338386 #341963 #342835 #344700 #348679 #359171 #359619 #365644
#375073 #385631 #417689 #419501 #428825 #437291 #444831 #446298
#448385 #453935 #457188 #462393 #464428 #465241 #478116 #480743
#484714 #486454 #488081 #490547 #497297 #498566 #498800 #501588
#501855 #502766 #508428 #509100 #512034 #514348 #516823 #536869
#537571 #537735 #529403 #540978 #541844 #542264 #548505 #555014
#555043 #555896 #556881 #559194 #559431 #561747 #564545 #565760
#566343 #567545 #569315 #570492 #574132 #574928 #575999 #576319
#579384 #587087 #590595 #590604 #591892 #598485 #599790 #610845
#612001 #613276 #615151 #631525 #637483 #638049 #639011 #641756
#643997 #644544 #648313 #649267 #651410 #655483 #658635 #658640
#663134 #663699 #618753 #661678

Note that while these are somehow related to resolving dependencies
not all are actually in resolver.

Still at least about half of them is.

cjwatson wrote:
> I'm uploading 0.6.6-1ubuntu1 to precise now. However, I'm not closing
> this bug at this point, because I'm not convinced it entirely fixes it
> (and upstream doesn't appear to truly claim that it does).

Correct -- as previously mentioned, the problem resolver is not
intelligent in it's handling of m-a situations.

I was very particular in closing bugs with the changelog.

> The
> directions in the bug description still produce a certain degree of
> chaos; Daniel, do you think you could try those out?

I am sure that they do. I can not say when I will next have sufficient
time to look at this.

I suspect this can be fixed with a relatively minor change, any C++
hackers can investigate the source files
src/generic/problemresolver/* src/generic/apt/aptitude_resolver*
for potential solutions.

Dear Friends,

From Ubuntu precise release notes:
"Aptitude does not work on 64-bit systems without disabling multiarch in /etc/dpkg/dpkg.cfg.d/multiarch . (831768)"

This is wrong! Aptitude works now!

Thanks and Blessings,
Shahar

On Thu, Apr 26, 2012 at 03:05:20PM -0000, Shahar Or wrote:
> This is wrong! Aptitude works now!

The logs of this bug are distinctly ambiguous on the subject :-)

On 26 April 2012 18:37, Colin Watson <email address hidden> wrote:

> On Thu, Apr 26, 2012 at 03:05:20PM -0000, Shahar Or wrote:
> > This is wrong! Aptitude works now!
>
> The logs of this bug are distinctly ambiguous on the subject :-)
>

I informed the release team about it.

Thanks.

>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/831768
>
> Title:
> aptitude cannot handle conflicts with multiarch enabled
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/aptitude/+bug/831768/+subscriptions
>

Well it was still broken yesterday evening ;-)

On 26 April 2012 20:35, Swâmi Petaramesh <email address hidden> wrote:

> Well it was still broken yesterday evening ;-)
>

It's resolver is not so hot but to say that it "does not work" is a bit
misleading!

>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/831768
>
> Title:
> aptitude cannot handle conflicts with multiarch enabled
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/aptitude/+bug/831768/+subscriptions
>

I know this isn't a referendum, I just found these two cents in my pocket.

Shahar wrote:
> It's resolver is not so hot but to say that it "does not work" is a bit misleading!

For what little it's worth, it looks that way to me, too. I can only see that aptitude 'works' on a level it had not since multiarch began. I have used aptitude for the great majority of its existence, about ten years. Comparing the present Ubuntu package to those experiences:

- I don't recall a time when the resolver worked much better for me, than 0.6.6 does. I don't want to paper over the weaknesses of the resolver, at all. I can't see that, with the recent multiarch patch, they've regressed a lot from the time before multiarch. I don't have test cases to offer, and anyone who does may trump my personal experience.

- Aptitude under multiarch was very broken for me; not really usable, until the recent 0.6.6.

- I now use it as I did in the past. It seems restored to the previous level of functionality, for me, and I keep thinking "this is great, I have aptitude back!"

So perhaps someone will have a good wording to describe the situation accurately. Acknowledge whatever clear regressions still exist, since pre-multiarch. And convey that aptitude, in 12.04, works much, much more than it did in the last few releases. If I had not been following Precise all along, that is the information I would want to know.

I don't have a comprehensive picture of everyone's experience, of course. This is just my attempt to contribute to it, and I have no great complaint with the situation as it is. Thanks.

On Apr 27, 2012 2:10 AM, "Edward Donovan" <email address hidden> wrote:
>
> I know this isn't a referendum, I just found these two cents in my
> pocket.
>
> Shahar wrote:
> > It's resolver is not so hot but to say that it "does not work" is a bit
misleading!
>
> For what little it's worth, it looks that way to me, too. I can only
> see that aptitude 'works' on a level it had not since multiarch began.
> I have used aptitude for the great majority of its existence, about ten
> years. Comparing the present Ubuntu package to those experiences:
>
> - I don't recall a time when the resolver worked much better for me,
> than 0.6.6 does. I don't want to paper over the weaknesses of the
> resolver, at all. I can't see that, with the recent multiarch patch,
> they've regressed a lot from the time before multiarch. I don't have
> test cases to offer, and anyone who does may trump my personal
> experience.
>
> - Aptitude under multiarch was very broken for me; not really usable,
> until the recent 0.6.6.
>
> - I now use it as I did in the past. It seems restored to the previous
> level of functionality, for me, and I keep thinking "this is great, I
> have aptitude back!"
>
> So perhaps someone will have a good wording to describe the situation
> accurately. Acknowledge whatever clear regressions still exist, since
> pre-multiarch. And convey that aptitude, in 12.04, works much, much
> more than it did in the last few releases. If I had not been following
> Precise all along, that is the information I would want to know.

Great! Thank you, Edward! My thoughts exactly.
>
> I don't have a comprehensive picture of everyone's experience, of
> course. This is just my attempt to contribute to it, and I have no
> great complaint with the situation as it is. Thanks.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/831768
>
> Title:
> aptitude cannot handle conflicts with multiarch enabled
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/aptitude/+bug/831768/+subscriptions

On 27 April 2012 11:12, Daniel Hartwig <email address hidden> wrote:
> ** Description changed:
>
>  TEST CASE:
>  1. Enable multiarch (should be automatic on new oneiric systems)
>  2. Install an i386 package on amd64 (like flashplugin-installer:i386)
>  3. Mark something with a lot of dependencies for installation
>  4. On the confirmation screen, try to remove on of the dependencies (aptitude will now fail to perform upgrades when there's a package conflict w/out removing the i386 libs)

This is not specific to multiarch.

If you enable a repository with random conflicts with your current
base system and install a package from such repository you get into
this situation. Foreign arch on multiarch system is one of such
possible repositories. Third party repositories often cause similar
issues.

>
>  This renders aptitude painful on a multiarch enabled system (default in
>  oneiric).

on any system with complex dependencies.

> This is not specific to multiarch.

Agreed, though this test case is. I have only included the workaround in the description as many users are likely to land here due to the release notes.

Also, this report does not need more comments about:

- the mention in 12.04 release notes, including the wording;
- whether the resolver is generally working or not working; or
- whether aptitude works or not with multi-arch.

I have today unmerged ~4 bugs which were not related to the issue
identified in the report description. Some of those are fixed,
others are not. Also removed are the watches on unrelated bugs
from bugs.d.o.

Please do not merge in other bug reports not related to multi-arch
conflict resolution as this will confuse the issue. It is possible that
the resolver can be made more useful for m-a while still being
broken with complex conflicts in general.

This is a very serious issue. I just upgraded to 12.04 and currenly I cannot even install wine without getting dependency errors. apt-get want me to resolve it by removing about 200 packages. I vote to give this bug critical status.

On 13 May 2012 03:17, Lanoxx <email address hidden> wrote:
> This is a very serious issue. I just upgraded to 12.04 and currenly I
> cannot even install wine without getting dependency errors. apt-get want
> me to resolve it by removing about 200 packages.

It is my understanding that apt-get works well in these situations --
did you mean that *aptitude* wants to remove those packages?

If you must install foreign-arch packages and aptitude gives you
grief, use another package manager.

> I vote to give this bug
> critical status.
>

While I'm certain that some people have attempted to fix this (myself
included), to my knowledge there is no one doing this currently.
Twiddling the bug status is not going to change anyone's priorities[1]
nor will it magically conjure a fix.

Aptitude's developers are volunteers. Ubuntu provides other package
managers which do not have this problem.

I suspect that "voting" with your hands by submitting a patch will be
far more effective.

Maybe I misunderstand the meaning of the "importance" bit. I thought it was importance to the functioning of this package, so that availability of other package managers is irrelevant to its setting.

While changing the bug's importance doesn't change anyone's priorities in fixing aptitude, it does accurately reflect the status of this bug for the usage of aptitude in current ubuntu: for those using multiarch, it makes aptitude just about useless, if not worse (when silly enough to listen to its' recomendations of what to change/delete).

I personally decided to remove it until this is fixed, despite having used it in preference to apt-get etc. for several years as I find it easier to get a good idea of dependencies (and especially conflicts) for packages.

But right now starting aptitude means waiting for it to go through a mass of conflict resolution to reach a faulty end-solution., and then having to look through the false positive conflicts/brokenness information, and discarding those (remove xx pagackes - and then most of the rest of the system thanks to dependencies? no thanks) before being able to do anything. So high does seem on the low side, and critical is more accurate.

The only time I use aptitude is to remove all redundant files as in:
aptitude purge ~c
Is there an equivalent that uses apt-get instead?

Dealing with the problem resolver is difficult and time consuming. A project has been start on fossfactory.org to fund work on this bug. The aim of fossfactory.org is for interested users to pledge funds to attract developers to work on the projects they care about. When a particular feature or bug is done, then the developer who fixes it claims the bounty which users have pledged.

Please consider pledging to get this bug resolved[1], or to one of the parent projects which cover general development[2] and multi-arch work[3] on aptitude. A pledge to the parent project will still put some funds in to resolving this bug.

[1] http://www.fossfactory.org/project/p316
[2] http://www.fossfactory.org/project/p306
[3] http://www.fossfactory.org/project/p314

The funds that accumulate in these bounties will certainly help to attract a new developer or two and keep the project alive.

Colin, is there any more that can realistically be done here for .1?

Thanks for the hint, Daniel.

I have been using aptitude for over 10 years now. It's still the best package manager I know and I hate seeing it deteriorate in such a way.

That's why I have offered 100€ on Fossfactory for fixing this bug[1]. I know this is alone is not enough. But 333 people are "affected by this bug" (according to Launchpad). With a few of dollars from each one of us it should be possible.

[1] http://www.fossfactory.org/project/p316

I've chipped in at $56.09, raising it to $222.35.

Given the need for upstream work, nothing else is going to realistically get done for .1, although I've left it at precise-updates in case some backportable upstream work happens later. (I can't do any more myself, so unassigning myself.)

Guys offering money bounty's to solve the Aptitude multiarch problem please make sure you Donate to Daniel Burrows (the writer of Aptitude)

http://algebraicthunk.net/~dburrows/projects/aptitude/donating/

A large influx of donations with a mention of please fix multiarch might be a great motivator for Daniel to fix this.

Attached patch updates the problem resolver to better handle
multi-arch situations so that it no longer gets stuck trying to remove
all foreign-arch packages.

Affected users and interested persons should perform testing and
review on this. The changes are relatively small but there is room
for regressions in complex dependency situations.

The patch has been developed and tested with aptitude 0.6.8.

If this works or does not work for you please comment, particularly if
you experience regressions.

Daniel, thank you for the patch!
Just finished building 0.6.6 with "multiarch-conflicts.patch" applied. Run aptitude and update went OK. However, after update and pressing CTRL+G I see that aptitude still unable to understand that libqt4-gui both i386 and amd64 can coesist like apt-get does.
Tested with Aptitude::ProblemResolver::StepLimit "0"; hack applied.

So no improvement for me... Shall I use 0.6.8 aptitude version and try again?

On 4 August 2012 17:12, Fyodor Kupchik <email address hidden> wrote:
> However, after update
> and pressing CTRL+G I see that aptitude still unable to
> understand that libqt4-gui both i386 and amd64 can coesist
> like apt-get does.

libqt4-gui is not multi-arch: same and apt-get does not support
installing on both amd64 and i386:

# apt-get -s install libqt4-gui:i386 libqt4-gui:amd64
…
The following packages have unmet dependencies:
 libqt4-gui:amd64 : Conflicts: libqt4-gui but 4:4.8.2-2 is to be installed
 libqt4-gui : Conflicts: libqt4-gui:amd64 but 4:4.8.2-2 is to be installed

Do you instead mean the libraries depended on by libqt4-gui
(libqt4-designer, -opengl, -svg, libqtgui4)?

> Tested with Aptitude::ProblemResolver::StepLimit "0"; hack applied.

You should remove that when testing the problem resolver.

Hi Daniel, thanks for the patch! It looks good to me so far.

I patched and built the current version from Quantal, 0.6.6-1ubuntu2.

In the fullscreen text interface, I played around, marking needed packages for deletion. The resolver only showed the actual dependencies as problems, and didn't flag any foreign-arch packages. Without the patch, I certainly hit the bug: whenever a conflict comes up, it wants to remove all the i386 packages from my amd64 system.

I'll try to keep testing it in normal use for a while.

(I tried to build it against 0.6.8 from the debian source, but the gtest stuff wouldn't build. I was compiling it with dpkg-buildpackage, and couldn't find how to skip building those tests.)

Thanks.

On 6 August 2012 03:15, Edward Donovan <email address hidden> wrote:
> (I tried to build it against 0.6.8 from the debian source, but the gtest
> stuff wouldn't build. I was compiling it with dpkg-buildpackage, and
> couldn't find how to skip building those tests.)

After review of the changes between .6 and .8, the patch should be fine on .6.

Having said that, you can skip building the tests with the standard mechanism:

$ export DEB_BUILD_OPTIONS="nocheck"
$ dpkg-buildpackage …

There is also a patch with Ubuntu specific changes for .8 attached to
Bug #824708.

Thanks, Daniel. Hopefully I'll have some time to build and test against 0.6.8, soon. In the meantime, with the patched 0.6.6, I dealt with a bunch of dependency problems today, and the patch continued to work fine. The resolver came up a lot, and never wanted to remove my foreign-arch packages. It's nice.

Fyodor, you reported “no improvement.” Are you able to provide an update given my previous response?

Hi, Daniel!

Sorry for late answer, I was not able to reach my workstation to test better new patch. What I did today:
I disabled the hack mentioned in bug description, run aptitude and it showed "Suggest 228 removals 27 keeps." That is because after last update I did (don't remember exactly if I used apt-get or aptitude) aptitude was reinstalled from official repo so patched version was replaced.
Then I used dpkg -i to install patched version. After installation I've run aptitude again and it suggested only 4 removals and 29 keeps. I decided to let it to proceed with update even being noticed that it wants to remove skype 4.0.0.7. Pressed SHIFT+1 to apply solution and warning disappeared. In general I would say that update looked as "normal" not taking in account skype and ia32-libs which were removed. The main thing I've noticed that it didn't want to remove qt-gui stuff which is necessary to get skype to work.
After update went successfully I downloaded new skype package from skype.com i386 version and installed it. Everything went OK!

So here's is *definitely improvement* for me and disabling the option in /etc/apt/apt.conf did the trick for me!
Thank you very much for your work! I'm now able to use aptitude again!

On 7 August 2012 13:44, Fyodor Kupchik <email address hidden> wrote:
> After update went successfully I downloaded new skype package
> from skype.com i386 version and installed it. Everything went OK!
>
> So here's is *definitely improvement* for me and disabling the
> option in /etc/apt/apt.conf did the trick for me!
> Thank you very much for your work! I'm now able to use aptitude
> again!

Thanks for the update.

Anyone else using a workaround should be sure to disable it as
well.

I got time to build 0.6.8 with the patch applied, now that 0.6.8 is in Ubuntu. (It's great having bug 824708 fixed.)

It continues to work for me. I can't trigger the remove-all-multiarch behavior. I've tried marking important packages like apt, unity, or libc6 for removal, and it only shows me the genuine dependency problems this would create. If anyone knows some tricker tests, I'll try them. Thanks.

(I should write more carefully and call it "remove all foreign arch" behavior. At any rate, it's gone. Thanks.)

An update for Oneiric should also include the fixes for other serious multi-arch issues. At least Bug #845136 and Bug #904486. Without these multi-arch on that release is still effectively broken; IMO those bugs should be nominated also for Oneiric.

The specific patches for those issues may be fairly entangled, it may be easier to update Oneiric to at least 0.6.6 instead (currently at 0.6.4). My time as upstream maintainer is limited and I will definitely not be able to backport those fixes (or others that may arise) to 0.6.4.

For me multiarch-conflicts.patch seems to work fine and aptitude now doesn't want to remove all my foreign arch packages anymore.

Thanks everyone. I think we have enough user confirmations of the patch now.

As 0.6.8.1 version of aptitude fixed that bug I merged it into version for quantal. Please check package from http://tygrysek.juszkiewicz.com.pl/~hrw/ubuntu/

Thanks Marcin. This release doesn't seem to need an FFe as it looks like bugfix only, so I've swapped the subscription to ubuntu-sponsors for you. I suggest you attach a debdiff over Debian to make sponsoring easier.

Thanks, yes please include a debdiff, and a couple SRU fields still need to be filled out. Please re-subscribe ubuntu-sponsors when this work has been completed.

The details on the sponsorship overview are incorrect. This is currently only a request to get the fixed version (0.6.8.1) merged in Quantal. As per the previous comment, that release is only a bug fix.

> As 0.6.8.1 version of aptitude fixed that bug I merged it into version for quantal. Please check package from http://tygrysek.juszkiewicz.com.pl/~hrw/ubuntu/

Is a backport for precise available? Is anyone working on this?

I think (maybe) the problem is finally fixed with v0.6.8.1
As you know, "ppa-purge" used "aptitude". I have updated the system with the Xorg Edgers PPA repository. I installed "aptitude" v0.6.8.1 in Kubuntu 12.04 Precise. Then ppa-purge has been able to resolve dependencies. It uninstalled google earth and its :i386 dependencies but I have yet some i386 packages installed and the system is not broken.
To install aptitude v0.6.8.1 on Precise, you go to Ubuntu Packages:
http://packages.ubuntu.com/
And search and download the following packages for "Quantal" (not for Precise):

apt
libapt-pkg
libboost-iostreams
libept

Then download from the link posted by Marcin Juszkiewicz ( http://tygrysek.juszkiewicz.com.pl/~hrw/ubuntu ) the next packages:

aptitude-common
aptitude

Save all packages in the same folder. Open the terminal in that folder and install with:

sudo dpkg -i *.deb

Thanks to the developers and creators of the patch.

> Then ppa-purge has been able to resolve dependencies

I mean using "ppa-purge" with Xorg Edgers PPA.

Sorry, I've rushed.
Now "aptitude" v0.6.8.1 on Precise can not resolve dependencies when trying to install Google Earth:
http://pastebin.com/eu2ua79c

apt-get can install without problems.

On 3 October 2012 03:27, YAFU <email address hidden> wrote:
> Sorry, I've rushed.
> Now "aptitude" v0.6.8.1 on Precise can not resolve dependencies when trying to install Google Earth:
> http://pastebin.com/eu2ua79c

The proposed solution there looks fine to me, remove some -dev and
misc. packages whose dependencies are being upgraded (and thus, no
longer met). I'm sure one of the subsequent offerings will be to
upgrade most of those packages instead.

>
> apt-get can install without problems.

Please provide the typescript of apt-get for comparison. You should
also skip through several solutions offered by aptitude so that we can
see what is being considered—the order is some times not what the user
expects.

If you wish to pursue this as an issue file a new report as your
experience is not that covered by this bug.

@Daniel, this is apt-get output:
http://pastebin.com/XBy5CbSH

>If you wish to pursue this as an issue file a new report as your
>experience is not that covered by this bug.

Ok, before I will continue experimenting with aptitude

According to comments here, the 0.6.8.1 release is considered fine for inclusion in quantal by the release team and works for everyone that has tested it. So after some quick smoke tests of my own, I've uploaded it to quantal.

According to comment 104, SRUs are not necessarily requested by this bug. I will close the SRU tasks for precise and oneiric. I'm not sure this would fit the definition of a good SRU candidate anyway.

This bug was fixed in the package aptitude - 0.6.8.1-2ubuntu1

---------------
aptitude (0.6.8.1-2ubuntu1) quantal; urgency=low

  * Resynchronise with Debian to pick up multi-arch fixes (LP: #831768).
    Remaining changes:
    - debian/05aptitude: Never autoremove kernels.
    - Drop aptitude-doc to Suggests.
    - 03_branding: Ubuntu branding.
    - 04_changelog: Take changelogs from changelogs.ubuntu.com.
    - 14_html2text_preferred: Switch back to html2text in favor of elinks,
      since html2text is in main and elinks isn't. Convert all files to utf-8
      encoding as it is better then ascii for iso-8859-1 (English docs).
    - no-google-mock: Don't use google-mock as it and libgtest-dev are in
      universe. Refreshed to cover all changes.
 -- Michael Terry <email address hidden> Wed, 03 Oct 2012 22:55:21 -0400

On 4 October 2012 22:14, Michael Terry <email address hidden> wrote:
> So after some quick smoke tests of my own, I've uploaded it
> to quantal.

Appreciated.

> According to comment 104, SRUs are not necessarily requested by this
> bug.

From that comment, with emphasis added:

> This is *currently* only a request to get the fixed
> version (0.6.8.1) merged in Quantal.

The SRUs are not requested yet as the fix [was] not in Quantal. That
comment addresses the prior one regarding various SRU fields not being
filled out and where the commenter appeared mislead by the status of
the sponsoring overview (showing “SRU” instead of “merge”).

> I will close the SRU tasks for precise and oneiric. I'm not sure
> this would fit the definition of a good SRU candidate anyway.

Not being sure about the candidacy should you rather leave it open to
be adjusted by someone who is?

Please confirm your action with the person who opened those tasks or
one of the numerous @ubuntu.com people assigned and otherwise involved
over the course of the bugs life.[1]

As someone familiar with the issue I request that you reopen those
tasks to their previous status and immediately assign them to cjwatson
(previously assigned) or someone else who is informed about this bug.
Such a person is in a better position to take the appropriate
action(s) now required.

Regards

[1] CC to bring this back to their attention now that it is resolved.

> Not being sure about the candidacy should you rather leave it open to
> be adjusted by someone who is?

Saying I wasn't sure was a polite way to say that it didn't seem like a good candidate to me, but I'm happy to have someone else that thinks otherwise push them in.

Additionally, I had read comment #85 as saying that Colin was not interested in pursuing it for precise, but now I think that was a misreading. So I'll open these back up as you request.

On Fri, Oct 05, 2012 at 09:08:34AM +0800, Daniel Hartwig wrote:
> As someone familiar with the issue I request that you reopen those
> tasks to their previous status and immediately assign them to cjwatson
> (previously assigned) or someone else who is informed about this bug.

Please don't assign these tasks to me. I won't have time to deal with
them.

I have tested the precise patch in combination with my ppa-purge patch (Bug #892886), and everything seems to be working smoothly as far as purging packages on a multiarch precise system now.

I'm going to unsubscribe the sponsors team until someone from the SRU team can verify this is the sort of patch that would be accepted. I'd like to get it off the sponsors queue, since there is not anything immediately actionable here from that front.

If you can get buy-in from the SRU team, please re-subscribe the sponsors team. Until then, please don't subscribe them. Thanks!

[1] indicates to have a sponsor upload to -proposed before the Sru team
will review. It states there is no need to wait. The package is unusable
on m-a systems, in Ubuntu main, this upload is a self-contained fix: why
you consider it so unsuitable?

If the package does not get to -proposed, how else to bring this to sru
teams attention?

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Procedure

@ Ubuntu SRU Team

Subscribing ubuntu-sru-team.

The precise.debdiff attached to this bug-report is ready for upload into proposed. But there is no clear consensus if such an update is inline with SRU requirements. Can you please review and evaluate the rist of this SRU.

Ubuntu SRU Team

Based on the date of your subscription (2012-11-08) the fix /would/ be one of the five oldest entries in the unapproved queue for Precise. It does not appear in that queue as ubuntu-sponsors have declined to upload without prior consideration by your team.

Please consider the report, or at least comment that the team is aware of it.

It's a bit scary and would need a lot of testing, but the very poor state of aptitude on multiarch systems in affected releases is a sufficient reason to try for an SRU; so, Dmitrijs or other sponsors, go ahead and upload.

(However, I would suggest removing the "Lack of upstream support" section from "Impact"; true or not, this has no direct bearing on whether we update packages in stable releases.)

This has been sitting in the queue for ages. It's a shame that we haven't gotten around to uploading this by now (admittedly I myself have had a sponsoring session or two in this time and didn't touch it). I'm building aptitude now and will upload to precise-proposed if it passes smoke tests.

Given the magnitude of this SRU I think extensive testing will be warranted, if it is accepted. Perhaps the waiting period could be extended from 7 days.

I don't know what to upload to Q; please provide a clean debdiff if you wish for an SRU to be uploaded there too. Otherwise, we can leave it as is.

So, sponsoring to precise, for what it's worth. I couldn't do much meaningful local testing with multi-arch, possibly because I have some core-ish packages built for amd64 but not i386 in a local repo.

Done. Unsubscribing sponsors now. Please resubscribe if there's anything else for us to do, such as sponsoring to Q if a debdiff is provided.

Laney, pretty sure it was already fixed in Q,via upstream.

I tested it quite extensively, way back when I was patching ppa-purge. No longer have a precise box to test on though.

On 17 April 2013 17:25, Tim <email address hidden> wrote:
> Laney, pretty sure it was already fixed in Q,via upstream.

Confirm this, with upstream hat on. The fix appears from version 0.6.8.1.

Okey doke. The bug still asks for a fix for Oneiric, but I don't know if anyone will be interested in that any more. Thanks!

Hello Micah, or anyone else affected,

Accepted aptitude into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/aptitude/0.6.6-1ubuntu1.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

The newly uploaded 0.6.6-1ubuntu1.2 version works perfectly for me on a reasonably complicated Precise server with a mixture of i386 and amd64 packages.

Upon starting aptitude, it immediately started complaining about broken packages and all sorts of fixes that it wanted to apply to fix all sorts of problems, so I was skeptical at first. However, this turned out to be because of some pending actions that aptitude still remembered from the last time that I ran aptitude (months ago, just to test whether the problem with multiarch had been fixed without me noticing). Telling aptitude to forget all pending actions got me a perfectly clean system according to aptitude.

Thanks for all the efforts, I love aptitude very much, although I've gotten used to using apt-get as well now :-) Aptitude is much easier to use for selectively upgrading packages, though, which is sometimes necessary on my servers to minimize downtime caused by package upgrades.

aptitude_0.6.6-1ubuntu1.2_amd64 from precise-proposed fixes this issue for me.

I checked by trying to install wine. The dependency resolution only grumbles about one “recommends” which can't be resolved, which is probably okay. Before it would try to remove (almost?) every package installed.

On 22 April 2013 18:38, Stephan Springer <email address hidden> wrote:
> I checked by trying to install wine. The dependency resolution only
> grumbles about one “recommends” which can't be resolved, which is
> probably okay.

gettext?

Yes:

 Actions Undo Package Resolver Search Options Views Help
C-T: Menu ?: Help q: Quit u: Update g: Download/Install/Remove Pkgs
                   Packages Resolve Dependencies
  --\ Keep the following packages at their current version:
    gettext-base:i386 [UNINST]
    gettext:i386 [UNINST]
  --\ Leave the following recommendations unresolved:
    wine1.4-i386:i386 recommends gettext:i386

wine1.4-i386:i386 recommends gettext:i386
--\ The following actions will resolve this dependency:
  -> Install gettext:i386 [0.18.1.1-5ubuntu3 (<NULL>)]
  -> Leave the dependency "wine1.4-i386:i386 recommends gettext:i386" unresolved.

[1(1)/...] Suggest 2 keeps
e: Examine !: Apply .: Next ,: Previous

On 22 April 2013 20:30, Stephan Springer <email address hidden> wrote:
> Yes:

See bug #954029. Trivial fix, could be SRU.

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

This bug was fixed in the package aptitude - 0.6.6-1ubuntu1.2

---------------
aptitude (0.6.6-1ubuntu1.2) precise-proposed; urgency=low

  * Apply upstream multiarch-conflicts.patch to handle conflicts on
    multi-arch systems. (LP: #831768)
 -- Daniel Hartwig <email address hidden> Thu, 08 Nov 2012 14:28:23 +0800

Incomplete for too long. No detail given why this should be specifically filed against Baltix.

Oneiric is no longer supported.