Re: phasing out override files
My two ideas:
1. Perhaps the override file entry should simply be made optional, rather
than dpkg-scanpackages needing it. If a package is in the override file,
its priority/section are overriden. If it's not, then the value used in
the control file is considered authoritative. I realize that this means
a massive scan for control files when Packages is updated.
2. Perhaps a better implementation would be to auto-generate the overrides
file from a real set of overrides (i.e. information differing from what's
in the control file), and the packages' control files. This can then be
done at a lesser enough frequency to keep from absolutely destroying
master with scans for control file contents - the archive tools could
continue using the overrides file; the file would just be generated in
a different way now.
I feel that using packages' control info directly except when it's in
the override file would be the best thing, but somehow I doubt that
it's very plausible resource-wise ;). #2 means less work for the archive
maintainers because overrides aren't needed for *every* package, allows
us to retain a way of changing a package's section and priority, and lets
us manually specify info for those packages w/o it in the control file -
all with a bit more resource usage (think weekly scans here).
Just my $0.02 (ok, more like $20.00...)
On Mon, May 01, 2000 at 09:10:15PM -0700, Joey Hess <joeyh@debian.org> spake forth:
> 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.
--
Mike Markley <mike@markley.org>
PGP: 0xA9592D4D 62 A7 11 E2 23 AD 4F 57 27 05 1A 76 56 92 D5 F6
GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084
I am pleased to see that we have differences. May we together become
greater than the sum of both of us.
- Surak of Vulcan, "The Savage Curtain", stardate 5906.4
Reply to: