Raphael Hertzog wrote: > As I can understand him, we really should respect his wish. If Matthias agrees, > I can extract the "dependency" generation code from dh_python and create > a little perl library that would be included in the python package > (or python-dev) and that would be used by dh_pysupport and dh_pycentral. > I can also prepare patches for dh_pysupport/dh_pycentral. If I were you, I would probably make that a little python program that they can call. Up to you of course. > python-support/central will have to depend on the new debhelper to avoid > generating dependencies twice if dh_python is invoked (as is currently > the case for most packages). > > The new debhelper will have to be uploaded together with the new > python-support/central to avoid any problem (If it is uploaded before, > some packages may not have dependencies at all. If it is uploaded after, > python-support/central won't be installable.) Shouldn't be a problem as long as both python-support and python-central can be modified.. > > Not all packages use the new python policy yet. For example, debconf > > doesn't. I'm not sure if that's a bug or not. One alternative would be > > reverting dh_python to the pre-NMU version (plus a small shim to make it > > a no-op if it detects the new policy), to avoid breaking such packages > > until they transition. > > Indeed, for me it appears unavoidable (cf my suggestion above). > And we must also coordinate the upload of the new version of the > packages. BTW, the main reason debconf doesn't use either method is because AFAIK neither is written to be used by an effectively essential package, which still needs to install if python is broken, not available, or too old. I may have to end up writing my own postinst code in debconf to deal with that, since the old method is also not very robust (#225384). -- see shy jo
Attachment:
signature.asc
Description: Digital signature