On Sun, Aug 19, 2012 at 12:44:44AM +0200, Jonas Smedegaard wrote: > On 12-08-18 at 10:19pm, Andreas Tille wrote: > > 1. The new field Files-Excluded in debian/copyright contains > > a space separated list of regular expressions. > > The deletion process will loop over every expression > > > > rm -rf ${MAIN_SOURCE_DIR}/<expression> > > Copyright file format emplicitly emphasizes that the globbing is not > shell style but find style. > > I believe it is better to loop over either of these expressions: > > find ${MAIN_SOURCE_DIR}/* -path <expression> -delete > > find ${MAIN_SOURCE_DIR}/* type f -name <expression> -delete > > The latter is when item does not contain "/".
ACK. > > 4. In case something was removed the version string will be appended by > > '+dfsg' to express the fact that the content of the original source > > was changed. > > Suffix should be configurable. > > I use ~dfsg by default, ~dfsg1 and bumping numbers for multiple > repackagings, and only +dfsg when the repackaging happens after a > non-repackaged version was released into Debian. > > Reason for this is that there is a slight chance upstream may re-release > same upstream version repackaged to fix a purely tarball-related issuem > and I would then have room for using that proper version instead of > using epoch or add a bogus .0 to the version. This was also my initial idea when firt proposing ~dfsg. On the other hand: I would *really* want to have upstream adding a new version number to the cleaned up release. It is just (uhmm, find your own word here) if people release the same named file with different content. So I do not see great harm if we would settle with +dfsg. Gregor, could you give better reasons than Jonas for +dfsg? I'm personally a friend of adding one feature (the removal of files) first. Later we could add additional features like configuring suffixes and compression methods. > > For the implementation of this it waqs suggested to > > > > use Debian::Copyright; > > That initial test by Gregor makes me worry if Debian::Copyright parser > might be too strict: Writing should be strict but parsing relaxed - > Copyright file format with undefined fields added should *not* be > treated as broken. Perhaps there are other surprises waiting to happen > :-/ Could anybody say something about this? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120819101957.gc12...@an3as.eu