[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Enabling uupdate to simply remove files from upstream source (Was: Minified javascript files)

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 "/".

> >  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



Reply to: