The Freemail ebuild creates a /var/freenet/plugins directory owned by root:root. That directory must be owned by freenet or freenet will not be able to load any plugins other than freemail. Freemail probably should not create the plugins directory in the first place - freenet should create that directory when the user loads a plugin, or the freenet ebuild should create it. Please fix this.
Best would be to only use ebuilds for plugins instead of downloading the binary ones, but for the time being, i committed a workaround to change the ownership of that dir. If you sync in a few hours or later, it should be in your local tree. Please remember that using those plugins is at your own risk (both precompiled and they are live plugins, no real versioning). And for your information: The ebuild has to create the dir, else it cannot create a symlink in there and freenet wont be able to load the Freemail plugin provided by the ebuild. Freenet ebuild should not do it, simply because it does not install plugins, so there is no need to create that dir. And freenet itself will create the plugins dir, if you load a plugin via freenet webinterface (be aware that it uses direct http access to the freenet download server) and there is no plugins dir.
On using ebuilds for plugins, I agree with you for sure. At some point, there ought to be some sort of freenet-plugins-official ebuild that would install JSTUN, UPnP and all the other official freenet plugins, with the exception of freemail, which already has its own ebuild and ought to stay in its own ebuild simply because it is a fully fledged email server and people ought to be able to find it in their /usr/portage/net-mail directories. But as far as the plugins directory is concerned, every ebuild that provides a plugin for freenet ought not to have to dodir /var/freenet/plugins and fperms freenet:freenet /var/freenet/plugins. If we really need that directory created by an ebuild, there is no reason it shouldn't be the freenet ebuild. Freemail and freenet-plugins-official have freenet as a runtime dependency and the plugins they install could not perform any useful function without it. On the other hand, I really see no reason to create that directory at all. I have in my /var/freenet directory a JSTUN directory and a UPnP directory, each containing the respective plugins. From the freenet plugins page, I simply typed their relative paths into the 'Add an Unofficial Plugin' form, i.e. JSTUN/JSTUN-r24902.jar and UPnP/UPnP-r24903.jar. Upon loading the plugins, the appropriate symlinks were created in /var/freenet/plugins/ by freenet. It seems to me that this is the most appropriate way to do this. The only downside to this approach is that the user has to type in a relative path, because freenet (for some reason) doesn't understand absolute paths. To work around this, I would actually suggest that freenet plugin ebuilds might want to actually place their plugins in /var/freenet/<whichever-plugin>/ directories as I did, and then it's not so tough for the user to enter the relative path. Of course, if you still want to place the plugins in /usr/share/<whichever-plugin>/lib/ it would still make sense to make a symlink to it in /var/freenet/<whichever-plugin>/, just because otherwise it will be a hassle for the user to enter the path. This seems like the most elegant solution, since the freenet plugins directory gets to be created by freenet itself and no ebuild has to touch it at all, and freenet gets to create the symlink just like it's supposed to - what would happen if at some point a change in the freenet code caused it to choke because it found a symlink in it's plugin directory that it wasn't expecting - that would clearly be bad news and the user would probably find himself unable to use freenet for awhile. So, I strongly suggest that we do away with creating the plugins directory entirely, and feel free to send me an e-mail if you want to talk about the freenet-plugins-official ebuild. I've actually considered writing it myself, the only problem is I don't know anything about java, and I've never compiled a java program so I'm very unqualified to write it :(
