Re: Updated python-support
On Mon, 19 Jun 2006, Andreas Barth wrote:
> > * Automatic dependency generation in dh_pysupport, removing the
> > need to run dh_python.
>
> You mean, this change breaks compatibility with the previous versions of
> python-support? I strongly recommend to not make such a change.
Joss agrees that dh_python should be responsible for the dependencies, we
just need to find a common ground on how to do it. I posted my analysis
and my proposal already.
> > The last change is a source of strong disagreement between Raphaël and
> > myself. Having seen the result of messing up with dpkg's database and
> > control fields [0,1],
>
> Eh, I'm sure you can explain where somebody messed up with dpkg's
> database? What you can see is "only" that some programs postinst failed
> to run successfully. You can get the same results with just calling
> /bin/false inside of postinst.
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.
> 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.
> > and I've done things the Debian way, with a debian/package.pyversions
> > file, like helper scripts have always done.
>
> This is not enough, as we need to be able to extract information from
> the control file. This is also important for the release team and QA
> team's tools. You basically need to use the new python policy.
We don't need to. It has been acknowledged by some people that it would
make it easier to track packages. On the other hand, it's not that
complicated to find packages depending on "python (<< 2.X)" which will
obviously need an update for the python transition.
> The policy is valid enough.
Unfortunately, the python policy can only be enforced either if it's
integrated in the main policy or if the release team decides to enforce it
for whatever reason.
My discussion with Steve Langasek however leads me to the conclusion that
the RM will only enforce the most important new python packaging rules:
arch:all must provide the modules to all supported python versions and
arch:any must provide all the .so if possible.
However the absence or presence of a header is unlikely to constitute a RC
bug for the release team.
Furthermore, the policy should always document the existing rather than
force people into a given direction. So it's unlikely that it will be
integrated in the main policy also.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Reply to: