On Mon, Aug 20, 2012 at 12:10:19AM +0200, gregor herrmann wrote:
> > > 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?
> Well, I see Jonas' point but I haven't encountered it yet in my
> experience; and often repackaging happens after detecticting that
> it's needed, in which case +dfsg seems more logical.
I confirm that this case seems the more probable case to my experience.
I also agree that a configurable suffix would be interesting but my main
focus is currently the implementation of the deletion process and the
configurable suffix could be added as an additional feature later.
> > > 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
> > > :-/
> Yup, I was just the first that came to my mind.
> > Could anybody say something about this?
> Next guess:
> Dpkg::Control::Hash - parse and manipulate a block of RFC822-like fields
How would you compare this to Jonas solution using
? I'm to inexperienced with these tools to weight pros and cons.
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com