Galeon can be built with more mozilla versions. It is not best idea to depend on single version: 1.2.8 - Compatible with 1.01, 1.1, 1.2.1, 1.3a, 1.3b 1.2.7 - Compatible with 1.0.1, 1.1, 1.2 1.2.6 - Compatible with 1.0.x, 1.1.x and 1.2a Maybe we can add two dependencies for all ebuilds: >=net-www/mozilla-${REQ_MOZ_VER}* <=net-www/mozilla-${MAX_MOZ_VER}* Reproducible: Always Steps to Reproduce:
Can you also please suggest how to automatically (in a way that works with -binary- packages) detect and depend on the right version of mozilla? The reason here is that galeon has to be run against the same version it was compiled against, and also needs a compile-time flag for the version/branch in use. to make this work with building would require some hacking logic (what differs the mozilla versions, find and fix with the compile-time-flag) but would also completely bork with any form of binary package since we cannot dynamically depend on "any" mozilla version then. so, the current way is actually designed as such to avoid breakage. (ramble provided to give a sense of clarity in the issue) Wontfix unless you can figure this out for me.
This is valid for many other packages, that upgrade of some library breaks package, but it is not reason to hardwire any version to ebuild. For example, updating of some GNOME components breaks all binaries dependent on it. This breakage should be solved in general way by portage, not by packages (another bad example is gnome-extra/gal, where porters provide links to old, possibly incompatible libraries). I think it is not so bad to allow more versions of mozilla. If one upgrades mozilla and forgets to recompile galeon, galeon will show warning recommending recompilation.
*** Bug 17285 has been marked as a duplicate of this bug. ***
*** Bug 17286 has been marked as a duplicate of this bug. ***
still, using binary hacks to find what we depend on is ugly. -very- so. azarah, you've been handling most of the mozilla integration so far, your take on this is?
my take is that we should never make it depend on a mozilla _dev_ release. And the choice between 1.0.1 and 1.2.1 still imo should be fairly obvious be the 1.2.1 release because of improved stability and performance. I dont really see the problem, the ppl who do notice this can get around it easily by fixing the ebuild themselves. The others (biggest bunch out there) should get the best possible version (and imo that would be eg. galeon-1.2.8 against moz-1.2.1 ). And the gal example isn't imo really relevant, cause it shouldnt really break compatability (since 0.18 or so 0.23 seems the first one that does) while we know that mozilla does. And i don't like the current gal situation at all, but it's the best solution at this time (we cannot force rebuilds of reverse deps).
Not allowing mozilla dev causes cyclic mozilla recompilation 1.2.1 <-> 1.3b in devel branch (ACCEPT_KEYWORDS="~x86"). After each odd ACCEPT_KEYWORDS="~x86" emerge --update --deep world galeon become broken and after each even it become again working. I have few ideas about targetting reverse deps for recompilation, but these ideas will be here off-topic.
Well, I fixed it to be able to detect the installed version of mozilla: ------------------------------------------------------- local moz_ver="`pkg-config --modversion mozilla-xpcom | cut -d. -f1,2 2>/dev/null`" [ -z "${moz_ver}" ] && moz_ver="${REQ_MOZ_VER}" ---------------------------------------------------------- Thus if you have mozilla 1.3b installed (like me), you can just emerge galeon, no problem. Anybody however that do reside to the unstable tree, should fairly know what they are doing. MEANING they SHOULD know that downgrading mozilla will need a galeon recompile. Anyhow, Galeon do biatch about this. My take: if you use unstable, or mix it, you should: emerge -u --deep world -p AND THEN DECIDE WHAT TO UPDATE MANUALLY. Else please use stable and stop bitching.
'fix it' == 'close it' :)
