removal of arch-all packages while there are arch-specific packages dependent on it results in uninstallable binaries

Note that DAK didn't do this either, so this is a feature request.

Good canddate for discussion in Paris. Thank you Lamont.

Lamont, we ended not discussing this at all. Is it still worth doing after all this time, I can preview that making 'domination' aware of reversed deps is not going to be easy.

And bug #209515 request pretty much the same thing for PPA domain.

High: we support ARM as a primary arch and it often hits this.

So I'd like to blow the dust on this bug, and like to get this implemented; archive skewing has caused considerable issues with reliably building images on ARM, and prevented our daily image builds from succeeding and has caused us to miss multiple milestones due to the extensive build time required for some ARM packages like libreoffice.

Debian has done work in implementing this in dak, so it might be possible to look at their implementation on a sane way to implement this in Soyuz: http://ftp-master.debian.org/wiki/projects/arch-all-tracking/

Julian and I discussed this at length over lunch yesterday, and came to the conclusion that the correct (though, admittedly, more difficult to implement) solution should be to make arch:all a proper (but special-cased) architecture in Soyuz, thus allowing us to give arch:all packages their own BPRs and only garbage-collect them when the source is superseded.

Happy to discuss this further and help the Launchpad team spec out a proper LEP for it once we feel like we're ready to move on implementation.

This was escalated on the stakeholders list on behalf of the ARM team. Although the "proper" solution seems like "feature-scope" work that would outside of the maintenance-squad mandate, we should look if there is a dirt-cheap work-around that could work, otherwise, we should write a LEP to take through the stakeholders process for feature-squad assignment.

@rreynoso45 I'm so glad you're working on this. I've marked it as assigned to you for clarity. If you need any help or mentoring please just ask here, on our IRC channel (irc.freenode.net, #launchpad-dev) or the mailing list (https://launchpad.net/~launchpad-dev).

Looks like Rachel may be confused (based on a separate question bac pointed me at) rather than working on this; toggling the metadata back - if you are actually working on it please feel free to reset appropriately.

Why is the easy solution (a special-case check when removing the files from the archive) not a good idea?

It may be; this is scheduled to be worked on by a maintenance squad, but so is a lot of stuff; we can reasonably expect team red to pick it up shortly when they wrap up derived distros.

I suspect removal from the archive is too late a stage to handle this properly. But good news: as of just a few weeks, the Dominator supports multiple live versions of the same package in the same context. So one of the long-standing obstacles may now be out of the way.

On Tuesday 04 October 2011 12:15:03 you wrote:
> I suspect removal from the archive is too late a stage to handle this
> properly. But good news: as of just a few weeks, the Dominator supports
> multiple live versions of the same package in the same context. So one
> of the long-standing obstacles may now be out of the way.

Removal is far too late indeed, they need to remain in the index.

Fixed in stable r14159 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/14159>.

This breaks domination between arch-indep and arch-specific binaries. http://paste.ubuntu.com/711550/ is a test that shows this.

I'm reverting this and landing the new test.

Fixed in stable r14169 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/14169>.