[Bash-completion-devel] New directory layout

[Guillaume Rousse]

Santiago M. Mola a écrit :
> El sáb, 17-01-2009 a las 13:21 +0200, Ville Skyttä escribió:
>> On Friday 16 January 2009, Santiago M. Mola wrote:
>>> El vie, 16-01-2009 a las 20:22 +0100, David Paleino escribió:
>>>> On Thu, 15 Jan 2009 23:18:16 +0200, Ville Skyttä wrote:
>>>>> Directory where OS default modules (e.g. ones enabled at additional
>>>>> package install time) are symlinked to, everything loaded by
>>>>> bash_completion; sysadmins or users should not touch this dir or its
>>>>> contents.  Tools that manage system wide modules should operate on
>>>>> these files,
>>>>> not /etc/bash_completion.d/ ones:
>>>>>     /var/lib/bash-completion # or maybe bash[-_]completion.d ?
>>>> I don't really like /var/lib/ -- but I'd have to check FHS for any other
>>>> suitable directory.
>>> I don't like it either. And it's not FHS compliant anyway:
>>>
>>> From FHS:
>>> ----
>>> /var/lib : Variable state information
>>> Purpose
>>> This hierarchy holds state information pertaining to an application or
>>> the system. State information is data that programs modify while they
>>> run, and that pertains to one specific host. Users must never need to
>>> modify files in /var/lib to configure a package's operation.
>>> ----
>> FHS compliance is the reason why I suggested /var/lib/bash-completion, and I 
>> think for the intended purpose it would be compliant.  No actual modules 
>> would ever be *installed* there.  It would just be a directory where modules 
>> to be enabled are *symlinked* to on per host basis (== state information for 
>> one specific host) *by tools* that enable/disable them (== programs modify 
>> while they run, state information for those tools, users don't modify).
> 
> Ok, I completely misunderstood the point initially. Looks like something
> to consider then.
I'd still prefer to use /etc/bash_completion.d for this, because setting 
which completions are globally activated seems more like configuration 
than a program state. The whole /var hierarchy is generally dedicated to 
program writing stuff themselves, not admins. If we had caching in some 
functions, it would make sense to use it, tough.

-- 
Guillaume Rousse
Service des Moyens Informatiques
INRIA Saclay - Île-de-France
Parc Orsay Université, 4 rue J. Monod
91893 Orsay Cedex France
Tel: 01 69 35 69 62