#11520 closed (fixed)
Release tarball includes useless ".DS_Store" files
Reported by: | Chris Lamb | Owned by: | nobody |
---|---|---|---|
Component: | Uncategorized | Version: | |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
The 1.1 RC1 tarball contains a few MacOS resource fork files:
$ wget -q http://media.djangoproject.com/releases/1.1/Django-1.1-rc-1.tar.gz $ tar xfz Django-1.1-rc-1.tar.gz $ find -name "*.DS_Store" ./Django-1.1-rc-1/django/contrib/admin/media/js/._.DS_Store ./Django-1.1-rc-1/django/contrib/admin/media/js/.DS_Store $
Such files are generally useless and I (with Debian maintainer hat on) have to strip them out.
Change History (7)
comment:1 by , 15 years ago
comment:3 by , 15 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
There's no reason to re-roll the rc tarball, but we'll be sure to get this worked out when we push the final.
comment:4 by , 15 years ago
Resolution: | invalid |
---|---|
Status: | closed → reopened |
Back in the 1.2~alpha release tarball:
./docs/._.DS_Store
./docs/.DS_Store
./django/contrib/admin/media/js/._.DS_Store
./django/contrib/admin/media/js/.DS_Store
Whilst I understand that final releases may not have these files, it would seem to make sense to either not have a seperate release process for "final" vs. "non-final" tarballs.
comment:5 by , 15 years ago
milestone: | 1.1 → 1.2 |
---|---|
Triage Stage: | Unreviewed → Accepted |
The issue here is making sure ubernostrum's packaging script clears out these files (or that he packages a clean checkout). Marking for milestone 1.2 so that it isn't forgotten, but it's a procedural issue, not a code fix that is required.
comment:6 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
This is fixed with the 1.2 beta package. The problem was with one tool ignoring the files while others didn't, and so I've just added another step to the process to guarantee that the tree which generates the release package is clean.
They're not resource fork files. They hold view information for the Finder (and happen to have a resource fork, the ._DS_Store file). Still useless in this context, of course. ;)