Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > I think you've misunderstood me. I felt Ansgar and I were discussing in > the abstract what would be the most optimal situation. Certainly I'm > not saying that policy should mandate the use of anything that doesn't > currently exist.
> I think that whether the general machinery for converting icons etc. for > the menu is sufficiently automatic/sophisticated is a matter for the > submitters of trad menu integration patches. Oh, okay. > IMO if those patches aren't unreasonable then maintainers should accept > them, even if they're slightly less automatic than would be ideal. Sure. I don't think anyone anywhere in this discussion was advocating rejecting contributed traditional menu entries in packages. I do think that "should" in Policy is stronger than that, and I don't think just weakening "should" for all of Policy is the right solution to this bug. I also don't know if Bill would be happy with a weaker version of "should" that's akin to how we handle man pages in practice. > Has anyone described any actual difficulties with supporting the > traditional menu ? Not that I'm personally aware of apart from there being yet one more piece of documentation to read and one more thing to have to pay attention to when packaging something new. The Policy bug started with a request for formally documenting and supporting desktop entries, and the question of what level of requirement was appropriate for menu came out of that, not out of a separate complaint. One other side note: Policy has a very clear and broad mandate for what should provide menu items, but I'm not sure that's widely known except to the DE packagers (who, because of that mandate, generally *don't* want to steer users towards the traditional menu). I don't think anyone previously has laid out the two systems the way that you did as having far different content *by design* instead of just by accident. I certainly hadn't been thinking of it that way. That may be an interesting way forward and remove a lot of tension. The traditional menu would be for absolutely everything and the kitchen sink, and desktop files would only be for programs that have reasonable integration into a more typical GUI environment. I think drawing that distinction clearly in Policy (which it does not currently, since it doesn't mention desktop files at all, and which I don't think the proposed patch does either) would provide a lot more guidance about what people should do in practice and also provide more explicit blessing for window manager packagers who aren't interested in the all-encompassing menu to drop it (at least by default). That might be a useful way to resolve this conflict and put to rest the periodic arguments about whether, say, shells should have menu entries. They would have traditional menu entries but not desktop files, and we could say that explicitly. That leaves Policy requesting, at the level of should, that people provide integration for something that may not be that widely used, so I'd still like to see us develop some sort of standard wording for things that are more "would be nice" than "this is something you need to do for your package to be considered a good package." Assuming, that is, Bill is okay with putting traditional menu entries at that level. If not, then that's still an open question. I think doc-base integration is a fairly similar case, BTW. In that case, Policy says that it is "recommended practice," which policy defines as equivalent to "should." If anything, doc-base is probably less used by end users than the traditional menu. (Personally, I think man pages are more important than either, but man pages are also more work, and that's to some extent personal preference.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org