On dim, 2008-01-13 at 10:21 +0100, Peter Eisentraut wrote: > For a while now some folks have been going around asking various package > maintainers to inject dh_icons and/or dh_desktop calls into the package build > rules. The basic argument appears to be that your package needs to do this so > that my desktop environment will work correctly. I don't think this approach > has correct and sustainable principles. Debian has always been about integration. Don’t you register your documentation with doc-base so that your application integrates with centralized documentation systems? Don’t you register your fonts with defoma so that applications using it can actually see the fonts? The same goes for desktop environments. You need to register your icons so that they are correctly cached (icon loading is one of the biggest performance issues on desktops), and to register your desktop files so that the MIME registry works. > And what is more, if some random third > packages or user environments dictate what other, unrelated packages have to do > to function with them, we will in practice never reach a state where everything > works. It is not a random user environment. It is the accepted standard for the three main desktops we are shipping. > Furthermore, if other desktop environments come up with their own > variants of icon caching of MIME file registration (since these are supposedly > Free Desktop standards) or perhaps completely new file registration > requirements, we will have an unmaintainable mess of competing implementations > of registration scripts, and thousands of packages stuck in a transition > somewhere between all of them. But we are not talking about other desktop environments. If you were asked to use dh_desktop, it is because your application *does* ship Freedesktop .desktop files. If you were asked to use dh_icons, your package *does* include icons in the Freedesktop directory hierarchy. Furthermore, the update-mime-database and update-icon-caches commands have very simple APIs which mean we can replace them easily with other implementations if someone wants to design them. > It seems to me that, in principle, if some third package or user environment > wants something to be done for its own functional benefit, it should be its own > responsibility to arrange that, instead of bothering thousands of other > packages with it. Is it the desktop environment’s or the package’s own functional benefit to have the application launched when you click on a file of the related type, or to have a visible icon? This is merely a philosophical question. > This appears to be the only robust and maintainable > approach. On a technical level, the best approach would appear to be > implementing some sort of global dpkg postinst and postrm hooks. Perhaps there > are other ideas, but the current approach needs to stop; it won't work. I thought dpkg triggers had been sufficiently advertised, but it seems the mails haven’t reached the (deep ?) place you are living in. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `- our own. Resistance is futile.
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=