I think we should begin to consider putting control over a package's section and priority into the hands of the maintainer of the package, and phase out the overrides files. As it is, every maintainer controls every aspect of their package, except those 2 fields. It seems a little strange that we give developers root on every debian system, and let them display arbitrary text to the user in package descriptions and elsewhere, and let them specify complicated dependancy information, and so on -- and yet we don't trust them to determine simple values for section and priority. I suspect that if maintainers are made responsible for those fields, they will begin to use more care in picking and maintaining them, and this will lead in the end to less work all around. Past: Until a couple of years ago, packages didn't tend to have section and priority information contained directly inside them, although it was recorded in source packages and in .changes files and so on. In this situation, the override files were the repository for this extra information. Then a few years ago, people started passing -isp to dpkg-gencontrol, making there be a copy of the information in the .deb package as well. (I suspect I'm missing some history.) Present: The override file is used to determine where a package goes in the archive and the Section and Priority values for the Packages file. The information encoded in the .deb is ignored. Getting the information in the Packages file changed is a manual process that requires a bug report be filed, plus an interminable wait. Today, 81% of packages contain section and priority information. Of those, 80% have values that agree with the information in the overrides file. Future: ? I would like to see the information encoded in .deb files (and .changes file, etc) be used to detemrine where they are placed in the archive, and what section and priority appear in the Packages files. The idea is to move the control of this into the hands of the individual package maintainer, so they are responsible for it. Then I suspect that bugs would be filed, and the current 80% correctness value would increase. We shouldn't to do away with overrides files immediatly; those 20% of the packages that have bad values in them don't allow it. Also, the ftp maintainers need to be able to move packages around quickly in an emergency, so they still need override capabilities. Instead, the overrides files could be gradually phased out. Here's one plan to do that: * Add a new fourth field to the overrides files. If it is "trusted", the information in the .deb becomes trusted and is used. If it is "overridden", the information in the overrides file continues to take precidence. * Mark the 80% that got it right as trusted and the rest as overridden. * Whenever an overridden package is uploaded with a correct section and priority, mark it trusted. * If the ftp maintainers need to override a value from a package, they simply change its entry in the override files to overridden and edit it as needed. (And file a bug on the package, if it was trusted before, so the maintainer can know why they have overridden it, and correct his package.) FWIW, my packages will exactly match the overrides file after the next dinstall run, modulo bug #60334. -- see shy jo  See attached diff.  See http://bugs.debian.org/ftp.debian.org for such requests that were made as long as 2 years ago.
Description: Binary data