Opened 6 years ago

Closed 6 years ago

Last modified 4 years ago

#11520 closed (fixed)

Release tarball includes useless ".DS_Store" files

Reported by: lamby 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: UI/UX:

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 Changed 6 years ago by anonymous

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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. ;)

comment:2 Changed 6 years ago by anonymous

make dist should whack those.

comment:3 Changed 6 years ago by jacob

  • Resolution set to invalid
  • Status changed from new to 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 Changed 6 years ago by lamby

  • Resolution invalid deleted
  • Status changed from closed to 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 Changed 6 years ago by russellm

  • milestone changed from 1.1 to 1.2
  • Triage Stage changed from Unreviewed to 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 Changed 6 years ago by ubernostrum

  • Resolution set to fixed
  • Status changed from reopened to 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.

comment:7 Changed 4 years ago by jacob

  • milestone 1.2 deleted

Milestone 1.2 deleted

Note: See TracTickets for help on using tickets.
Back to Top