svn commit: r319792 - head/sysutils/fsc

[Eitan Adler]

On 4 June 2013 07:36, Baptiste Daroussin <bapt at freebsd.org> wrote:
> On Mon, Jun 03, 2013 at 06:04:13PM -0400, Tom Rhodes wrote:
>> On Mon, 3 Jun 2013 22:18:31 +0200
>> Baptiste Daroussin <bapt at FreeBSD.org> wrote:
>>
>> > On Mon, Jun 03, 2013 at 03:51:06PM -0400, Tom Rhodes wrote:
>> > > On Mon, 03 Jun 2013 13:12:37 -0500
>> > > Bryan Drewery <bdrewery at FreeBSD.org> wrote:
>> > >
>> > > > On 6/3/2013 12:30 PM, Tom Rhodes wrote:
>> > > > > On Mon, 03 Jun 2013 11:51:32 -0500
>> > > > > Bryan Drewery <bdrewery at FreeBSD.org> wrote:
>> > > > >
>> > > > >> This is bad form. If you are changing upstream code it should be a new
>> > > > >> release version, not a reroll. We frequently have problems with other
>> > > > >> upstreams doing this and should follow our own guidelines.
>> > > > >
>> > > > > I'm not bumping the version used for a simple gcc->clang warning
>> > > > > fix.  That's why I just bumped PORTVERSION.  If we want to do a
>> > > > > new version, I'll get ahold of the NetBSD people, who also work
>> > > > > with keeping a port, and discuss doing that.  In this case, it
>> > > > > was a simple fix rather than adding a 2 line patch to a files/
>> > > > > directory.
>> > > > >
>> > > >
>> > > > The proper way to do is this a new release, or a patch in files with a
>> > > > PORTREVISION, or a sed in post-patch. This is the convention. Rerolling
>> > > > upstream is a big no no. Rerolling is obscure and very frowned upon.
>> > > > This also impacts NetBSD if they are tracking checksums, and any other
>> > > > projects depending on the checksum of the upstream tarball.
>> > >
>> > > I'll look at bumping the release version - there are some other
>> > > changes that need made anyway, I just wanted to fix the build so
>> > > users could build it again.
>> >
>> > In that case a patch in files/ is the way to go.
>>
>> I think the changes are a version bump - I'm working with some
>> NetBSD people on this, so I'll discuss with them.
>>
>
> This right statement should have been to not reroll the distfile but rather to
> put a patch in files/ and bump portrevision.

Or, if possible, wait for upstream to release a new version.


-- 
Eitan Adler
Source, Ports, Doc committer
Bugmeister, Ports Security teams