On Sun, 2008-03-02 at 22:21 -0800, Russ Allbery wrote: > That only lists some of the subdirectories of your list (it's missing all > the stock/* ones) and doesn't use the same names (international instead of > intl, applications instead of apps). All of those seem like things that > could change on us, no? Argh, I guess that is true. I'm wondering if it would be OK to build-depend on the hicolor theme and extract the list of directories at build time. Hmm, seems error-prone though and build-dep bloating. Alternatively you could have the theme installed and have a pre-release hook that generates the directories from the hicolor theme package and sticks them in the lintian source package. > I wonder if desktop-file-validate would understand all of this. It's on > the list to look at whether we can replace the desktop checks in lintian > with it. I think that only understands .desktop files, not this icon stuff. > > The hicolor standard theme is specified in this: > > > > http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html > > Interesting, thanks. > > It would be really good if some of this information could be written up > from the perspective of a Debian package maintainer, since right now > there's approximately zero information anywhere for how to deal with > desktop files if one doesn't personally use Gnome or KDE and isn't > familiar with this whole system. I tried to figure this out for gnubg and > didn't have a lot of luck. > > I expect that a lot of the people (like me) who are doing that had no idea > what else to do, or that it was even kosher to install files into the > hicolor directory. > > There's a lot of Debian communication missing in this area, I think. > lintian can help somewhat, but right now people are working in a void, and > adding a few lintian checks probably wouldn't be nearly as useful as > writing a comprehensive guide to how a Debian maintainer should tackle > these issues. (And then lintian checks can reference the guide.) I definitely agree with this, unfortunately I have little time to spare on it. Perhaps the gtk/gnome & kde teams could contact upstream to help get such a guide, or maybe Ubuntu already has one > > Isn't this the standard for desktop files? > > > > http://standards.freedesktop.org/desktop-entry-spec/latest/ > > It claims to be, but it's actually the standard for Gnome desktop files. > *wry grin*. As I discovered when writing lintian checks against that > standard, KDE does something different and uses various fields that aren't > listed there. Let alone GnuSTEP, which is even weirder. > > lintian is currently trying to check sort of a subset of that > specification, only desktop files of a particular type, and with > additional workarounds for KDE-specific stuff that can't be checked. Ugh. > > I'd also like to see a lintian info/warning when a menu file is > > installed in the package, but a .desktop file is not. The reason for > > this is that in that case, GNOME users will not have the application in > > their menu unless they turned the Debian menu on, since it is off by > > default. > > The last time someone proposed this, it sparked a huge flamewar on > debian-devel. I'm not sure I want to wade back into that. Apparently the > GNOME maintainers disabled the Debian menu because they think it's largely > worthless, and just blindly reintroducing .desktop files for every .menu > file would restore the previous situation. > > Logically, if every .menu file should correspond to a .desktop file, the > GNOME maintainers could just include the Debian menu. Since they don't, > that indicates to me that some logic (not yet documented) should be > applied by Debian maintainers to decide whether or not to include a > desktop file. Right, I forgot about that flamewar. IMO, there should either be both, or none or just a .desktop file. The menu package should become a conduit from .desktop files to desktop systems that don't support the fdo specs. I don't think Debian will make progress on this for at least a release or two though. -- bye, pabs http://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part