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[2].
Today, 81% of packages contain section and priority information. Of those,
80% have values that agree with the information in the overrides file[1].
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
[1] See attached diff.
[2] See http://bugs.debian.org/ftp.debian.org for such requests that
were made as long as 2 years ago.
Attachment:
diff.gz
Description: Binary data