Axel Beckert wrote:
[…]
>> With that, we could add the prefix based site-functions directory,
>> but deprecate its use.
>
> Ack, that thought came to me also after having read your mail
> half-through. It though has the danger that some so far not active
> plugins will suddenly start to work. So we add least need to
> debian/zsh.bug-script.
>
> Currenty it only checks for packages that ship files in
> /usr/share/zsh/vendor-completions/ and
> /usr/share/zsh/vendor-functions/.
True. Although "normal" function don't get activated automatically. Only
files that match ‘_*’ in $fpath get activated automatically by compinit,
if the user calls that function in their configuration files.
>> That way, packages that disrespect the zsh package's policy still
>> work, while keeping the possibility of a clean system, in case all
>> package adhere to the policy. We could file a bunch of bugs for the
>> packages that are currently using /usr/share/zsh/site-functions
>> right now.
>
> Debian prefers lintian warnings over mass bug filing. Mass bug filing
> needs to be discussed on the debian-devel mailing list first.
That is fair.
> What I now still wonder to (hopefully) address Joey's issue:
>
> Is there a way to build the Debian zsh (respectively probably the
> zsh-dev) package in a way so that locally installed Zsh extensions get
> cleanly installed into /usr/local/ while Debian packages still install
> stuff to /usr/ (preferably these vendor-* directories)?
Well, I am not sure what "plugins" do in terms of installation proce-
dures. The only such package that I have written¹ ships a script that
asks you for a directory that it should use for deployment.
If I were to do some sort of automatic site-local installation, I'd pro-
bably install to this: zsh -c '${fpath[1]}'
> I wonder if something like a dh_zsh helper could help here (i.e. for
> the vendor-* directory part) as well.
I suppose we could make it do this:
Install files from the source directory, that are not generally instal-
led by the upstream installation process. I think that this is still
more often than not the case:
dh_zsh -c -s examples/_foobar contrib/_quux
dh_zsh -f -s examples/some-function
Similarly, move functions from the in the packaging root directory, in
case things get installed by the upstream installation procedure:
dh_zsh -c -p /usr/local/share/zsh/site-functions/_foobar
dh_zsh -f -p /usr/share/zsh/site-functions/some-function
The mnemonics here are:
-c → Completion system function; put into vendor-completions
-f → General, auto-loadable function file.
-s → From Source directory
-p → From package root directory.
I suppose we could also add a ‘-r’ option to make the process recursive.
In addition, we could add an automatic mode for stuff in the packaging
root directory, if called without arguments, which should fix naïve in-
stallation procedures automatically, due to zsh's convention about names
for completion functions:
- Scan these directories:
- /usr/local/share/zsh/site-functions
- /usr/share/zsh/site-functions
- Move files matching ‘_*’ to vendor-completions
- Move the other files to vendor-functions.
- Remove those two directories (they should be empty now)
I think that should support most installation schemes.
WDYT?
Regards, Frank
