Just a trivial issue: Firefox profile is stored in ~/.mozilla/firefox, so Thunderbird one should be stored in ~/.mozilla/thunderbird instead of ~/.thunderbird for uniformity. Afaik, this can be done by passing "--with-user-appdir=.mozilla/thunderbird" to Thunderbird configuration, and by moving the already present user profiles (if existant) to that dir. I purpose to add this directly to the eclass, calling explicitly "--with-user-appdir=.mozilla/firefox" also for Firefox (so we'll be sure it won't change position with a version change). For the profile directory move, we can else just print a warning at the end of the ebuild and the users will do it manually.
Thunderbird's configure script aborts if the path contains any slashes.
What error, exactly? If possible, we could always patch it.
From the configure script: # Check whether --with-user-appdir or --without-user-appdir was given. if test "${with_user_appdir+set}" = set; then withval="$with_user_appdir" val=`echo $withval` if echo "$val" | grep "\/" >/dev/null; then { echo "configure: error: "Homedir must be single relative path."" 1>&2; exit 1; } else MOZ_USER_DIR="$val" fi fi It's not just some error, it's an explicit check that I would expect was put in for a good reason. (No, I don't know what that reason is.)
Which is strange, because exactly the same check is in firefox, but it ends up putting its profile dir in ~/.mozilla/firefox. So I expected that this is the default behaviour coded somewhere in the sources. In fact, after a quick grep (for Firefox), it appears that browser/app/Makefile.in contains: line 220: -e "s|%MOZ_USER_DIR%|.mozilla/firefox|" \ Then, explicit check or not, the default the programmers thought about was with a subdir inside it. Then I checked Thunderbird: mail/app/Makefile.in: -e "s|%MOZ_USER_DIR%|.thunderbird|" \ So I'm gonna try to patch it and rebuild it. If successful, I'll tell you and we can integrate the small patch in Gentoo (if you want, of course).
Created attachment 40062 [details, diff] thunderbird-base-userdir.patch I'll attach a modified ebuild later.
Created attachment 40068 [details, diff] Patch to the ebuild The patch for the ebuild is ok, but the patch I posted before to the Makefile isn't. After finishing compiling it, /usr/lib/MozillaThunderbird/thunderbird contains the right line with MOD_USER_DIR, so the patch produced a correctly modified build. However, it doesn't start correctly, so probably there is some problem elsewhere in the code. I'll need to investigate further.
Ah, a thing not related to this bug, but I bumped across it and it's trivial so you could fix it without opening a new report: In installed file /usr/bin/thunderbird: # Workaround thunderbird needing -a Thunderbird # See http://bugzilla.mozilla.org/show_bug.cgi?id=247754 if [[ $zero == thunderbird ]]; then fgrep -q '"0.7"' ${MOZILLA_FIVE_HOME}/defaults/pref/thunderbird.js \ && zero=Thunderbird fi Should be: fgrep -q '"0.7"' ${MOZILLA_FIVE_HOME}/defaults/pref/all-thunderbird.js \
Firefox uses .mozilla as its default user-appdir, not .mozilla/firefox. It adds firefox to it somewhere else. (According to the configure script, that is. What you found suggests that the user-appdir switch is ignored, which doesn't make much sense to me.) It also uses other files and directories in .mozilla (.mozilla/plugins, for example). PS: Might Thunderbird not work if you don't yet have a .mozilla directory? Will it be able to figure out to create .mozilla before creating .mozilla/thunderbird?
As per comment #4, firefox does the same thing. the default MOZ_USER_DIR is .mozilla for both thunderbird and firefox, but if it isn't set explicitly by the configure with --with-user-appdir=[..] (and in gentoo it isn't), a sed is performed in both apps. The fact that firefox can create more than a dir deep and thunderbird cannot, as you suggest, is unlikely but possible, imho. But, having applied the patch, at least I should obtain an error, not the old ".thunderbird" created. So I don't think this is the case. I filed a bug also in bugzilla.mozilla.org. let's see if i get any further info.
Right, sorry, my mistake. Thunderbird's default in the configure script does indeed seem to be .mozilla. But I wasn't suggesting that Firefox knows how to create more than one directory deep, while Thunderbird doesn't. What I thought was that when Firefox tries to create .mozilla/firefox, it could succeed because it had to create .mozilla anyway for the other files it uses (meaning it would fail if it used .mozilla/subdir/firefox, as an example), while Thunderbird has no reason to create .mozilla first. And if my previous comments sounded too negative: I personally do like your idea, and if you get it working I know it's what I'll use, even if for whatever reason it won't get in portage.
> it had to create .mozilla anyway for the other files it uses What files? I previously tried to compile a firefox copy fetched from cvs (since I was looking forward a patch merged before the official mozilla.org next release) and gave "--with-user-appdir=.firefoxcvs" to the configure. If I remember correctly, I started it in a fresh account and no ~/.mozilla dir was created, while ~/.firefoxcvs appeared. I could be wrong, anyway, I did it a couple of months ago. :p > And if my previous comments sounded too negative: I personally do like your idea, and if you get it working I know it's what I'll use, even if for whatever reason it won't get in portage. No problem. Friends? :D
Cool :) My .mozilla contains appreg (file), firefox (directory), mozver.dat (file) and plugins (directory). I haven't installed Mozilla, and mozver.dat contains references to Firefox. Firefox used to use .firefox (IIRC) instead of .mozilla/firefox; do you know if your snapshot was from before or after that change?
heh, this is still more interesting. of: appreg (file), firefox (directory), mozver.dat (file) and plugins (directory), i have just: firefox (directory) and appreg (file) removing appreg and starting firefox doesn't raise any problem, and it is not re-created. Maybe they're related to installing new extensions? If this is the case, having a ~/.mozilla "super-dir" above firefox and thunderbird (and sunbird...) makes still more sense: all the plugins are moved from the firefox/otherapp profile to a more neutral dir (i.e. easily rm-able if something goes wrong). Just speculating, though. Anyway, I grepped through the source extensively, and i wasn't able to find any reason why the patch above wouldn't work. I should take a closer look at the code, but after all the MOZ_USER_DIR var is set dinamically in the "thunderbird" installed shell file (try to "vim /usr/lib/MozillaThunderbird/thunderbird"). I didn't find any hardcoded reference, so it's possible that is the ONLY reference put there by the mozilla build process, and thus the patch worked for what it had to do. The problem is: why does it still create ~/.thunderbird? Evil. Any volunteer for manually compiling thunderbird with the patch? ;) (remember to do a "MOZ_THUNDERBIRD=1 ./configure && make")
Being able to share plugins with Mozilla sounds like reason enough to me, even if it would make them *harder* to remove :) A grep -R \\.thunderbird /usr/lib/MozillaThunderbird showed only the thunderbird script, exactly what you found. I also searched in the jar files, but found nothing in those either.
Thanks for looking into this. I'd rather wait for thunderbird upstream to make this change themselves. There's no driving reason to do it at the distribution level. Since firefox made the switch voluntarily, I suspect we'll see thunderbird do it eventually as well.
