Comment 22 for bug 1394731

Just a note: grilo itself isn't an issue as per see, but we have multiple examples of those instances I guess throughout the archive (even kubuntu things).

As Steve told, let's focus on the main issue (actually I see many):
1. what to do in similar case where we have a build-dep/dep for build-time requirements where only community flavors are interested in?
2. how to ensure that the strict binary separation are not overlooked in the future? For instance, we have from the tracker source the libs in main, but not the tracker/miner services.
-> The canonical desktop team are ok to "support" the libs, but not the services.
-> What if one day, something starts to recommends/deps on the service. Then, an archive admin runs check-mir on the package and see " * tracker is in universe, but its source tracker is already in main; file an ubuntu-archive bug for promoting the current preferred alternative". The AA will then just promote it, without having the background info that the canonical desktop team didn't want to support the service, and we end up in the same situation.
3. what procedure to require the AA to follow in case of promotion/demotion so that we can get the historical context easily on launchpad?