Re: Updated python-support
Raphael Hertzog writes:
> Indeed but the number of postinst failures due to python-central have been
> quite high recently. python-central is quite new and nobody helped
> doko to test it... so it's self-evident that we would run into some
> problems while it matures. doko has been very responsive in fixing
> problems, so it wasn't that bad.
>
> What Josselin is criticizing is the fact that python-central heavily
> relies on the P-V field, it looks it up in /var/lib/dpkg/status and also
> uses /var/lib/dpkg/info/package.list to find out files to byte-compile.
> This is usage of internal interfaces of dpkg and it's also normal that
> people are reserved on this.
/var/lib/dpkg/info/package.list is not used. According to the dpkg
maintainers, /var/lib/dpkg/status is public enough to be used. tools
like grep-dctrl use this file as well. So python-central does not use
any internal interface for package installation and removal;
/var/lib/dpkg/status is only used for runtime installation, removal
and upgrade.
software which doesn't get used is slightly less tested. Even the
claim that python-support is well tested is fragile. See #373753.
That's no ranting, both packages certainly contain more bugs.
> > WTF? We discussed that in Mexico, we agreed on that in Mexico, and now
> > you tell us that you just decided by yourself you don't want to follow
> > the new policy any more? Is there any serious reason for it, or do you
> > just feel like it?
>
> That field is only a part of the new policy, most of it stays the same and
> the important part concerning the packaging still applies.
>
> Joss doesn't feel like using that field because it clutters the database,
> and introduces unnecessary complexities in several places.
The field doesn't serve the package maintainer alone; it helps RM to
identify packages which need to be transitioned, to identify packages
which need to be rebuilt for dropped or added runtimes. python-support
doesn't need to use the field. I fail to see, how the simple presence
of the field introduces "unnecessary complexities in several places"
for python support, if python-support ignores it and dh_python manages
the field. The field is not "python-central only"; python-central is
one user, the other usage is getting information about the packages
without looking at the contents of the package itself.
I tried to explain why the dpkg database is the primary place to store
the meta information. We certainly did clutter the database with the
pythonX.Y packages. I really do not consider these extra 30bytes per
package in favour of dropping 2/3 of the current python module and
extension packages as clutter.
Matthias
Reply to: