New releases do not reliably overwrite old ones
|Reported by:||holdenweb||Owned by:||packagers|
|Severity:||Release blocker||Keywords:||release engineering|
|Cc:||krzysiumed@…||Triage Stage:||Ready for checkin|
|Has patch:||yes||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
There have been several issues reported where .pyc files from older releases apparently outlive the installation of a newer release.
The reason for this is that currently releases appear to be cut without altering the modification date of distributed files. Thus a .py file has not been changed since Jan 12, 2007 will appear in the release with that modification date.
When the release is installed with distutils the new .py files will replace their older versions, but if the .pyc from the prior release was compiled *after* the new .py file was last modified in SVN the new file will appear older than its corresponding .pyc, and the compiled file from the prior release will be retained, to the consternation of the installing user.
The simplest fix for this would appear to be to change the release engineering process so that after extraction from SVN all source files are touched to bring their modification date close to that of the release.
Strictly speaking this might also be considered a distutils bug, but the issue has not been reported elsewhere.
Change History (20)
comment:1 Changed 8 years ago by kmtracey
- Needs documentation unset
- Needs tests unset
- Patch needs improvement unset
comment:3 Changed 7 years ago by jacob
- Triage Stage changed from Unreviewed to Design decision needed
comment:5 Changed 5 years ago by aaugustin
- Easy pickings unset
- Triage Stage changed from Design decision needed to Accepted
- UI/UX unset
Changed 4 years ago by krzysiumed
comment:16 Changed 4 years ago by aaugustin
- Owner changed from aaugustin to packagers
- Triage Stage changed from Accepted to Ready for checkin