Subject: Re: Consistency in mk/defaults/mk.conf
To: Roland Illig <rillig@NetBSD.org>
From: Hubert Feyrer <feyrer@cs.stevens.edu>
List: tech-pkg
Date: 11/15/2005 21:16:39
On Tue, 15 Nov 2005, Roland Illig wrote:
>>> $ pkglint print/acroread7
>>> ERROR: print/acroread7/Makefile:54: "ACROREAD_FONTPATH" may only
>>>    be set by the user, not the package.
>> 
>> That sounds useful!
>
> How ironically do you mean that? The exclamation mark confuses me. :)

Not at all - I think it's a good thing.


>>> Does anyone see any objections against changing type 1 definitions to type 
>>> 2 definitions where that makes sense? Which ones need further discussion?
>> 
>> Yes: You're moving the default*value* from the pkg's Makefile to that named 
>> file, basically spilling pkg data all over pkgsrc. I think that's not a 
>> good idea.
>
> There are three places where this default value is mentioned.
>
> - The commented out assigment.
> - The block comment below.
> - The package Makefile.
>
> Two of these are likely to be redundant, so why can't we remove them? 
> Otherwise we need to check from time to time that they still mention the same 
> value.

You're right. But two of these three places are "only" comments.

I'm not sure what the right thing here is...


> Therefore I suggest something like this in print/acroread7/Makefile:
>
> # Additional directories to search for fonts
> # (see mk/defaults/mk.conf for the default value of this variable)
> BUILD_DEFS+=    ACROREAD_FONTPATH

What are our options here?
a) move the (real) default to mk/defaults/mk.conf as you said above,
    which spreads pkg data over those places
b) have only comments in mk/defaults/mk.conf, and keep all the real data
    in the pkg Makefile?
c) others?

I think while I agree that outdated comments are bad, spreading the pkg 
data over several places sounds less appealing. To me.
Maybe others have an opinion.


>> How about simply looking for some assignment to the variable?
>
> I've done exactly this. Or did you mean to ignore assignments that are 
> commented out? That wouldn't work, as for example #SMART_MESSAGES=yes is 
> commented out, so packages redefining it could not be detected.

Sounds good.


   - Hubert