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? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1394731 Title: [MIR] grilo-plugins To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grilo-plugins/+bug/1394731/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
