Call for testers -- CONF_FILES variable

[Baptiste Daroussin]

On Thu, 14 Jul 2011 15:02:25 -0400, Eitan Adler wrote:
>> The reason I choose pkgconf (we can change that name) is that it 
>> concerns
>> only configuration files that the maintainers DO want.
>>
>> I want to make sure that maintainers are looking at the samples the 
>> proprose
>> to provide a usable sample, not the default one from the distfile 
>> (the
>> default one can still be provided as an example.)
>
> So, this suffix is only for configuration files that port maintainers
> write and included sample files from upstream
> would not have this suffix?
>
> Why would the maintainer be writing sample conf files? It is not the
> maintainer's job to write documentation for the upstream project. The
> only case I could see this becoming an issue is if the default
> configuration file ignores hier(1) and a REINPLACE is needed. I do
> _not_ want to see sample configuration files being written for ports
> unless a considerable amount of rework is needed to make the
> application run on FreeBSD.
>
>> I wanted that pkgng and the ports in general can manage default 
>> usable
>> configuration files, and to distinguish them from the samples. 
>> Thanks crees@
>> has done the job I wanted to do myself so that and he has done it 
>> right.
>
> I am confused. I thought Chris's option was for the upstream sample
> configuration files.My understanding is that it replaces the logic of
> "only delete the real config file if it does not differ from the
> sample file".  Why then does it matter who wrote the sample since the
> logic works the same way? Either we will need multiple copies of this
> macro, one for "official" files and the other for "package" files or
> the logic will still have to be replicated per port for non-included
> samples. IMHO the suffix (and type of sample file) should not be
> touched by the macro.
>
> Perhaps I misunderstand what will be new in pkgng or what this patch
> provides?


Once again the goal is for maintainers who wants to provides default 
working configuration with their ports.
Not to provide samples (aka documentation, aka examples)

What pkgng do is checking if a configuration files already exists if no 
it creates its using the default one provided by the ports (the 
.pkgconf) if it does exists it left it as is (not overwritting the 
configuration from users)

pkgng does it by itself, the patch from crees do it for pkg_tool (aka 
the now tools)

in other words it corresponds to the .rpmnew from the rpm world, pacnew 
for archlinux users, and I don't remember what are the equivalent for 
other packaging systems but most of them does have an equivalent.

Bapt