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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
