[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#655975: marked as done (britney: needs to grok multi-arch)



Your message dated Wed, 18 Sep 2013 11:17:27 +0100
with message-id <a9297aa225663add517588149771e935@mail.adsl.funky-badger.org>
and subject line Re: Bug#655975: [PATCH] Support :any architecture qualifiers for multiarch
has caused the Debian Bug report #655975,
regarding britney: needs to grok multi-arch
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
655975: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655975
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
User: release.debian.org@packages.debian.org
Usertags: britney

britney will need to be taught to understand how to migrate packages in
a world with cross-architecture dependencies.

At the very least, things like "foo/i386 depends on bar:amd64" should
work.  Might there be merit to also checking the values of the m-a
control fields and verifying that the resulting migration makes sense?

Regards,

Adam




--- End Message ---
--- Begin Message ---
On 2013-09-18 10:30, Niels Thykier wrote:
On 2013-09-18 09:17, Adam D. Barratt wrote:
On 2013-09-18 6:33, Niels Thykier wrote:
I think we should take this opportunity to get rid of the "empty"
PREDEPENDS slot (i.e. have the MULTIARCH field replace PREDEPENDS).
There is no point in having the empty slot for PREDEPENDS; yours truly was just too lazy to figure out how to remove it from the C code when I
merged PREDEPENDS into DEPENDS.
[...]
I've also attached a squashed diff showing the cumulative changes
relative to the live code.
[...]
I would probably go with the squashed diff (of the two approaches).

I already had the changes staged in a local tree, so I've pushed them as separate commits.

I've just updated the live checkout and rebuilt the C module, so this is all live now.

Regards,

Adam

--- End Message ---

Reply to: