Here are some ebuilds for sylpheed-claws 1.9.99 and its new set of plugins. What i've changed: * in sylpheed-claws ebuild: - removed nls USE flag (it seems there is no more configure option) - changed tools install path to honor $(get_libdir) (Actually, i don't have a 64bits system, but i guess that's where plugins install on such systems. Deserves to be checked by some 64bits people tho.) - removed the suffix options ("sylpheed-claws" is the standard now). And thus removed the postinst einfo too, since what the ebuild does is just to follow the standard. - cleaned up tools compilation (it's in the default make targets) and installation (removed a tool that has disappeared) * in all plugins: - updated SRC_URI for the new source - bumped versions (note that there have been a few API changes lately, and thus a few plugins like mailmbox and vcalendar where not compiling anymore) - removed the src_compile when equivalent to the default function - removed .a/.la files installation since noone use them (and it makes the "Load module" dialog a bit more intuitive) - updated some DEPEND (mostly added gtk+ for those who explicitly require it according to "objdump -p | grep NEEDED") - removed non-existent files from dodoc lines * added acpi_notifier plugin: geeks love that kind of useless feature... I've added a small patch to support the ibm-acpi interface, and fix a small bug (the patch has already been accepted by upstream, it will be in CVS this evening). * added synce plugin: it's something related to WinCE devices. I've made it compile fine, but i can't test it, so you may just ignore that one. * perl plugin: a few more cleanification, like putting the einfo in postinst, etc.
Created attachment 72106 [details] mail-client/sylpheed-claws/sylpheed-claws-1.9.99.ebuild
Created attachment 72107 [details] mail-client/sylpheed-claws-acpi-notifier/sylpheed-claws-acpi-notifier-0.3.ebuild
Created attachment 72108 [details, diff] mail-client/sylpheed-claws-acpi-notifier/files/acpi_notifier-0.3-ibm.patch
Created attachment 72109 [details] mail-client/sylpheed-claws-cachesaver/sylpheed-claws-cachesaver-0.5-r1.ebuild
Created attachment 72110 [details] mail-client/sylpheed-claws-etpan-privacy/sylpheed-claws-etpan-privacy-0.9-r1.ebuild
Created attachment 72111 [details] mail-client/sylpheed-claws-fetchinfo/sylpheed-claws-fetchinfo-0.4.6-r1.ebuild
Created attachment 72112 [details] mail-client/sylpheed-claws-maildir/sylpheed-claws-maildir-0.11.ebuild
Created attachment 72113 [details] mail-client/sylpheed-claws-mailmbox/sylpheed-claws-mailmbox-1.4.ebuild
Created attachment 72114 [details] mail-client/sylpheed-claws-perl/sylpheed-claws-perl-0.4-r1.ebuild
Created attachment 72115 [details] mail-client/sylpheed-claws-synce/sylpheed-claws-synce-0.2.ebuild
Created attachment 72116 [details] mail-client/sylpheed-claws-vcalendar/sylpheed-claws-vcalendar-1.8.ebuild
Created attachment 72117 [details] mail-client/sylpheed-claws/sylpheed-claws-1.9.99.ebuild Added cleanup of plugins/*.{a,la} in that one too.
Oh, and something i forgot to talk about: i wonder whether it would not be time to drop the virtual/sylpheed. It's only used by x11-themes/sylpheed-iconset, and the themes from this package are rather incomplete for use with Claws. Sure i've not made this change, but that's something worth considering imho.
(In reply to comment #0) > * in sylpheed-claws ebuild: > - removed nls USE flag (it seems there is no more configure option) OK > - changed tools install path to honor $(get_libdir) (Actually, i don't have a > 64bits system, but i guess that's where plugins install on such systems. > Deserves to be checked by some 64bits people tho.) Tools != Plugins. The plugins should go to libdir (thanks for pointing that out), the tools (which aren't libraries) shouldn't. > - removed the suffix options ("sylpheed-claws" is the standard now). And thus > removed the postinst einfo too, since what the ebuild does is just to follow the > standard. OK for the einfo, but the ewarn is still required. > - cleaned up tools compilation (it's in the default make targets) and > installation (removed a tool that has disappeared) Ehm, I don't see anything related to this comment (other than the removed gpg-sign-syl) Will look at the plugins stuff tomorrow.
(In reply to comment #14) > Tools != Plugins. The plugins should go to libdir (thanks for pointing that > out), the tools (which aren't libraries) shouldn't. Well, i think that from a strict FHS point of view they should go in /usr/libexec/something, but i thought they would have been easier to find if they were close to the plugins, since that's where they were previously. Anyway, wherever you choose to put them, the same change should also be applied to the perl plugin then, which also installs a script in the tools directory. > > - cleaned up tools compilation (it's in the default make targets) and > > installation (removed a tool that has disappeared) > > Ehm, I don't see anything related to this comment (other than the removed > gpg-sign-syl) I've removed a "cd tools ; emake", because it was redundant since "tools" is in the subdirs of the top-level Makefile.
I've just seen the ebuild you have commited. I think you can remove this block from src_install, since the Makefile already the .desktop file at the right place now: dodir /usr/share/applications mv ${D}/usr/share/{gnome/apps/Internet,applications}/sylpheed-claws.desktop rm -rf ${D}/usr/share/gnome Also, i see you've not included the .a/.la cleanup in the plugins dir ("rm -f ${D}usr/lib*/sylpheed-claws/plugins/*.{a,la}"). Any cons on that one? I thought it was a good idea, since this files are really unlikely to ever be used by anything (btw, upstream's binary packages also only provide the .so). And finaly, a very minor cosmetic change you could have include was, in src_install: - local resdir + local res resdir
Ah, didn't look at src_compile when checking for the tools stuff so I missed that. The .a/.la stuff was covered by the "will look at plugins tomorrow" statement, though i took a bit longer than a day. Hmm, I still can't confirm the part about the sylpheed-claws.desktop location, it still installs into gnome/... here (also with just vanilla configure/make/make install), so needs further investigation, but low priority as it doesn't break anything AFAICS. As for tools location, yeah, lib isn't the best place but don't really know a better location (libexec is some dumping ground, and IIRC Mike wanted to get rid of it in favor of lib/misc some time ago), and as changing it can potentially break user configs I'll just stick with lib until some better place is found.
As for the plugins, why the revision bumps? AFAICS there is no reason for revbumps (e.g. for cachesaver) other than "encouraging" a recompile. Also gtk+ is already a transitive dep, so no point in adding it from my position.
Ok, Updated the broken plugins, added the .a/.la stuff to the latest versions of all plugins and added the acpi plugin. Will skip the synce plugin as I don't have a clue what it's good for and can't test it in any way, maybe at a later date.
(you've answered and commited stuffs while i was writing the below comment... Bah, pasting it anyway...) > I still can't confirm the part about the sylpheed-claws.desktop location, > it still installs into gnome/... here Oh, okay, got it. Installation paths of .desktop file and icons actually depend on what Gnome version has been detected: - Gnome 2 -> Freedesktop locations - Gnome 1 only -> obsolete locations - no Gnome -> no .desktop nor icon I think it's wrong and Freedesktop locations should be used in all case. You probably are in the "Gnome 1 only" case (are you?), and in this case your src_install() code makes perfect sense. What bother me more is the "no Gnome" case: it seems that this users won't have a .desktop at all, whereas this files are now used by many other desktops/WMs/menutools/whatever. I will see with upstream if they agree installing this files at the right place unconditionnally, or at least have a --freedesktop configure option or something like this. > As for the plugins, why the revision bumps? Removal of the .a/.la, although you're perfectly right it's actually not a big enough difference to worth a revbump. > Also gtk+ is already a transitive dep, so no point in adding it from my > position. Well, short answer is that i may be a too finicky on that; my opinion is that direct deps should be made explicit in ebuilds, but you're free to disagree and forget about that change. Long answer is that for automatic deps verification (stuffs similar to the "verify-rdepend" of portage 2.1), it is imho not safe to take transitive deps into account (but those listed in .la files - special case), because they can change too much across new versions of the depended-on packages (although in this case, it's quite unlikely that next version of sylpheed-claws will no more depend on gtk+), and thus ebuilds which shorten their rdeps list by removing "direct deps which are transitive anyway" would all be false-positive. But i agree it's a very minor concern since there is no official tool doing that kind of automatic verification (and all i have here is an embryon of code i've not touched for at least 1 year). Oh, and about plugins too, i've seen there is a .100 version too. That said, the only difference is that all plugins source code are in a "syslpheed-claws-external-plugins-1.9.100" directory, whereas they were at the root of the tar archive in .99. But the code is exactly the same. > libexec is some dumping ground, and IIRC Mike wanted to get rid of it Actually, i was sure libexec was an FHS thing, but after checking i see i was absolutly wrong. So you're right it's better to stay with /usr/lib, since it won't break for people already using that path and there is no obvious better place.
