Can we please just remove the old Makefile headers?

Bryan Drewery bryan at
Mon Aug 27 13:02:23 UTC 2012

On 8/27/2012 7:40 AM, Julian H. Stacey wrote:
> Brooks Davis wrote:
>> On Sun, Aug 26, 2012 at 02:02:47PM -0700, Doug Barton wrote:
>>> The old Makefile headers, ala:
>>> =20
>>> # New ports collection makefile for:    BIND 9.9.x
>>> # Date created:                         27 January 2012
>>> # Whom:                                 dougb
>>> #
>>> # $FreeBSD: head/dns/bind99/Makefile 301487 2012-07-24 19:23:23Z dougb $
>>> =20
>>> have not served a purpose for longer than almost anyone who has a ports
>>> commit bit has been around. My proposal is simple, let's remove
>>> everything before the # $FreeBSD$.
>>> =20
>>> In the past when this has been proposed the objection was that it would
>>> cause too much churn. If we had done this back when we had 5,000 ports
>>> then we would have solved the problem with less churn, and no drama for
>>> the 15,000 ports that followed. Every day we don't do this we make the
>>> "churn" problem worse, and deepen the roots of something that has no
>>> relevance.
>>> =20
>>> Can we please just deal with this now and be done with it? ... and yes,
>>> I am volunteering to help with and/or do the work myself.
>> Yes please!  We've got a nice repository that stores all the data in
>> question much more accurately than a silly header.
>> -- Brooks
> The example from original post of dns/bind99 is rather new, 
>> # New ports collection makefile for:    BIND 9.9.x
>> # Date created:                         27 January 2012
>> # Whom:                                 dougb
>> #
>> # $FreeBSD: head/dns/bind99/Makefile 301487 2012-07-24 19:23:23Z dougb $
> An older Makefile where "MAINTAINER=" evolved to no longer repeat "Whom:"
> # ports collection makefile for:        hylafax
> # Date created:         16 May 1995
> # Whom:                 Julian Stacey <jhs at>
> #
> # $FreeBSD: ports/comms/hylafax/Makefile,v 1.101 2010/09/19 12:04:42 dinoex Exp $
> ....
> MAINTAINER=     dinoex at
> Yes, first line seem disposable, repeating info in PORTNAME PORTVERSION
> 	# ports collection makefile for:	hylafax
> 	# New ports collection makefile for:    BIND 9.9.x
> But Whom & Date are useful on occasion.
>   On various other older ports, when I couldnt get response in time
>   from MAINTAINER (I don't mean re hylafax), perhaps maintainer on
>   holiday, & I couldn't wait for send-pr tiem out, & didnt want to
>   invoke send-pr, I fell back succesfully, to contacting the Whom:
>   creator, who while no longer regularly motivated to do maintenance,
>   could respond without delay & give hints (fallback maintainer).

I know several ports where this is the opposite of what the submitter
wants. They've long moved on and do not want to be bothered. Plus it
only adds to frustration to the reporter, who is sending a *2nd* email
to a *2nd* person who may not respond.

>   I presume some other users do that too, but we'd not see evidence
>   if people chose not to use send-pr (often a good thing to omit
>   initialy, eg when one isnt sure if one has a local mistake or
>   misunderstanding, or if there's a generic bug.)
> Hiding Whom in meta data would be bad:
>   Within a cvs or svn would make it much harder to access. ports.tgz
>   comes on CDs etc, all get it.  Less people have cvs, less still
>   svn, less svn mirrors, less people (outside commiters) will be
>   experienced/familiar with svn compared to cvs.

You can easily look on freshports.

>   Some ports are easy to create, eg my lang/pbasic, but some are
>   hard, (eg I'd guess editors/openoffice-3 may have been, One might ask 
>   	# Whom:                 Martin Blapp
>   comms/hylafax was a lot of work (whatever might show in Makefile,
>   getting run time interfaces sorted was Work).
>   Let ports creators retain their one line of credit.  Removing it
>   would save little & be ungrateful, like removing names out of .c
>   & .h.  (Some (inc. me) may like noticing in passing who created
>   the ports one's working on)).  The credit may encourage some ports
>   creators to struggle on, creating sometimes obdurate complex ports
>   one might otherwise be tempted to give up on after a not-yet-port
>   is just hand built & hand tested localy,

I actually agree fully with keeping their line of credit. But I disagree
that we should not remove or modify their email address on request from

> Cheers,
> Julian

Bryan Drewery
bdrewery at freenode/EFNet

More information about the freebsd-ports mailing list