brainstorming for UDS-N - Package Selection and Defaults

[Barry Warsaw]

On Oct 08, 2010, at 09:30 AM, Matthias Klose wrote:

>> OTOH, if we make it the default early, I think we can more effectively
>> identify and fix lots of ftbfs and .py incompatibilities before it affects
>> a large number of users.
>
>starting early is not the same as starting with it as the default, unless you 
>commit to work on build failures 7x24 for the first week.

Well, not 24x7 but yes, I do plan to work on it as a substantial part of my
time for Natty.

>> * If we keep 2.6 the default, what criteria would we use to make 2.7 the
>>    default and when would we have to make that by?  Possibly: all main
>>    packages build and install successfully by last alpha.
>
>reverting the default is not an option. plan the work that it can be done.

Why is reverting not possible?

If reverting is really not possible, then that decides it.  Scott's criteria
and schedule for switching the default to 2.7 works for me.  Once 2.7 is
supported I will work first on fixing ftbfs in main, but I will also work on
universe failures, and package installation failures (i.e. .py
incompatibilities).

>>> For the last release in the 2.x series it's important to
>>> finally get our robust-python-packaging spec implemented. that means:
>>>
>>>   - no symlinking in configure scripts
>>
>> robust-python-packaging asks whether we should backport PEP 3147 to Python
>> 2, and we decided we were not going to do that.  Ah, I think you mean this
>> bullet item:
>>
>> * Investigate amount of work to adopt dh_python2 to eliminate symlinks: TODO
>
>yes, this predates lucid.

Okay.

>>>   - all .py files distributed in the package, not created at configure
>>> time
>>
>> Do you mean .pyc files in the package?  Aren't the .py files already in the
>> package?
>
>No, the there is an absurdly high number of __init__.py files created at 
>installation time.

These are all namespace packages?

In upstream, Martin von Loewis is working on PEP 382, but of course that's
only for Python 3.2 at the earliest.  (I need to ping him and see where he's
at with that - Python 3.2 beta 1 is rapidly approaching.)

Correct me if I'm wrong but we talked about an approach for Python 2 where
we'd have a separate package that controlled just the namespace, laid down the
__init__.py for it, and was a dependent package for all the sub-packages.  Is
that still a reasonable approach?

>>>   - use of a unique site directory.
>>
>> This is not currently in the spec.
>
>no, but you found out about different site directories yourself, see #621348.

I've assigned this bug to me.

>> (Maverick spec):
>>
>> * Update dh_python to support versioned .so files: TODO
>
>I assume this is dh_python3, and already is done.

Right.

>
>> * Run 2to3 at build time: TODO
>
>depends, but out of scope of the python(2) specs.

Right.

>> * Investigate amount of work to adopt dh_python2 to eliminate symlinks: TODO
>
>yes, from my point of view this can only be done when we only ship the last 
>released python2 version.

Right.

>> * Add an auto-upgrade test profile that installs all/most of python (including
>>    universe) and tried to upgrade it and import all modules from 2.6, 2.7: TODO
>
>yes, I had the impression you already did this wit PPA test rebuilds (which
>got a lot faster recently).

Largely so, but I need to automate more of it.

>> * Keep source packages shared b/w 2 and 3 but split if upstream stops shipping
>>    py2 version: TODO
>
>well, that depends on the packagers decision. what will be do about this?

Probably not much except make recommendations and guidelines.

>> (Lucid spec):
>>
>> * make python-central use "include-links" as default (e.g. in dh_pycentral):
>>    TODO
>
>obsolete, all these packages should use dh_python2.

Right.

>> * rebuild all python-central packages in a PPA for testing: TODO
>
>not just these, all.

We won't need to rebuild them in a PPA though, right?

>> * use that PPA and do a test-upgrade (with python-regression test from the
>>    lts-upgrades spec): TODO
>
>again, all.

But not in a PPA?

>> * ensure python applications keep working between --unpack and --configure:
>>    TODO
>
>yes, I think this is trivial when all symlinks are shipped in the
>package. just do it.

+1

Thanks, I will update the relevant specs.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20101008/c1fa70fb/attachment.pgp