Sources (2)

Latest Comments

@swiftgeek This plugin at one point used to only provide silverlight support, and nothing else. This is a holdover from those days. By default no plugins are enabled. As majority of the people are using this for silverlight, the idea is to have the least number of ppl run manual disable/enable commands.

I'll change it to be only post_install instead of post_upgrade too, so that should fix your problem. As for the license, every package on aur with a custom license assumes you have accepted it on install, so I don't think that's really an issue.

Is `pipelight-plugin --accept --enable silverlight` seriously needed every update? Some people are not using pipelight for silverlight, and accepting license without user interaction also doesn't seem right…

In addition to the failed validity check listed in my previous comment, I had to update my system twice to even get that far because the first update said pacman couldn't find the correct version of wine-silverlight which is of course because it was about to be updated from AUR after I said N don't try to build pipelight again.

@sirrus23, aah thanks for catching that. This used to be doable in earlier versions of pipelight when there was only one config file, now it needs to be specified on a per plugin basis. Removing this option since it's no longer relevant.

The PKGBUILD script may have a flaw. The $_wineprefix variable is never used, and thus I think it is impossible to automatically install to any prefix other than .wine-pipelight

This can be worked around by uncommenting the line:
#sed -i "30s|.wine-pipelight|$_wineprefix|g" pipelight
But even this is inaccurate in terms of the line number and file to modify, and needs to be altered so that it reads:
sed -i "26s|.wine-pipelight|$_wineprefix|g" pipelight-*

This will cause pipelight's wine prefix to install to ~/$_wineprefix

The comment directly preceding this line states that the command will happen automatically if $_wineprefix is changed, but this seems to be false.