Responsible Changed From-To: freebsd-ports-bugs->gnome Over to maintainer(s).
In future, when you are going to submit another PR. Can you use the better word instead use 'EVIL'? Nothing personal about protect GNOME; it's just not clear enough when someone who are trying to read in the pkg-plist. Change from EVIL -> GNOME is more clearly enough to show it's GNOME option, IMO. :-) Cheers, Mezz -- bsdforums.org 's moderator, mezz.
On Sunday 07 March 2004 06:57, you wrote: > In future, when you are going to submit another PR. Can you use the better > word instead use 'EVIL'? Nothing personal about protect GNOME; it's just > not clear enough when someone who are trying to read in the pkg-plist. > Change from EVIL -> GNOME is more clearly enough to show it's GNOME > option, IMO. :-) > > Cheers, > Mezz Thanks for your response! I agree EVIL isn't a good name, I just figured it would be safe namespace wise. I sure don't mean to offend anyone, or obfuscate the port. :) Updated patch (s/EVIL/GNOME/) attached. sybolt
I can see one problem with proposed patch. At the moment main library consumers are ports from gnome land. This patch will change package configuration built on bento. And we get libgsf package incompatible with ports I mentioned before. Pehaps better aproach in this case will be creation of slave libgsf-gnome port. Just for the record what is the reason you want this option? This list will also be usefull for precise dependency targetting if we go the way I said. Thanks.
On Monday 08 March 2004 14:32, you wrote: > I can see one problem with proposed patch. At the moment main library > consumers are ports from gnome land. This patch will change package > configuration built on bento. And we get libgsf package incompatible > with ports I mentioned before. Pehaps better aproach in this case will > be creation of slave libgsf-gnome port. > Just for the record what is the reason you want this option? This list > will also be usefull for precise dependency targetting if we go the way > I said. > Thanks. Thanks for your comments! The reason I'd like to be able to build libgsf without gnome, is that I'd like to open msword documents in kword. For this to work, editors/koffice-kde3 needs textproc/wv2, which needs devel/libgsf. It seems silly to install many gnome packages - which I do not use - just to be able to read msword documents. :) I've done a little research to see how many packages really link with the gnome part of libgsf (libgsf-gnome-1.so.9): % find /usr/ports -name Makefile -mindepth 3 -maxdepth 3 \ | xargs egrep -l "gsf-1|gsf-gnome-1|libgsf" /usr/ports/textproc/wv2/Makefile /usr/ports/textproc/libwpd/Makefile /usr/ports/math/gnumeric2/Makefile /usr/ports/graphics/librsvg2/Makefile /usr/ports/devel/libgsf/Makefile /usr/ports/deskutils/planner/Makefile BTW with my patch applied, all of those will build just fine after # touch /usr/local/libdata/pkgconfig/libgsf-gnome-1.pc To see which ports really want to link with libgsf-gnome-1.so.9, I reverted to ports version of devel/libgsf, and rebuilt all of the above ports. A little script (attached) showed me this: % pkg_info -R libgsf-1.8.2_1 Information for libgsf-1.8.2_1: Required by: koffice-1.3,1 librsvg2-2.4.0_2 libwpd-0.7.1 planner-0.11_1 wv2-0.2.1_1 gnumeric2-1.2.6 % ./gsflink.sh koffice-1.3,1 /usr/local/lib/kde3/libmswordimport.so: libgsf-1.so.9 0x29694000 % ./gsflink.sh librsvg2-2.4.0_2 /usr/X11R6/bin/rsvg: libgsf-1.so.9 0x2807e000 /usr/X11R6/lib/gtk-2.0/2.2.0/loaders/svg_loader.so: libgsf-1.so.9 0x28520000 % ./gsflink.sh libwpd-0.7.1 /usr/local/bin/wpd2html: libgsf-1.so.9 0x280b4000 /usr/local/bin/wpd2raw: libgsf-1.so.9 0x280b3000 /usr/local/bin/wpd2text: libgsf-1.so.9 0x280b3000 /usr/local/lib/libwpd-1.so: libgsf-1.so.9 0x28193000 /usr/local/lib/libwpd-1.so.7: libgsf-1.so.9 0x28193000 % ./gsflink.sh planner-0.11_1 /usr/X11R6/bin/planner: libgsf-1.so.9 0x280de000 /usr/X11R6/lib/libplanner-1.so: libgsf-1.so.9 0x28185000 % ./gsflink.sh wv2-0.2.1_1 /usr/local/lib/libwv2.so: libgsf-1.so.9 0x282fd000 /usr/local/lib/libwv2.so.1: libgsf-1.so.9 0x282fd000 % ./gsflink.sh gnumeric2-1.2.6 /usr/X11R6/bin/gnumeric: libgsf-gnome-1.so.9 0x29137000 /usr/X11R6/bin/ssconvert: libgsf-gnome-1.so.9 0x29136000 /usr/X11R6/libexec/gnumeric-component: libgsf-gnome-1.so.9 0x29137000 Conclusion: of all the ports *explicitly* depending on libgsf, only gnumeric actually links with the gnome part (libgsf-gnome-1.so), and gnumeric doesn't need it to build (it does need libgsf-1.so.9). Now only if things were so simple! from Mk/bsd.gnome.mk I learned that USE_GNOME+=libgsf is implied by USE_GNOME+=librsvg2, which is implied by USE_GNOME+=*who knows what*. Since my computer isn't exactly build-cluster material, I don't have time/resources to build every single gnome port to check whether they somehow cheat and link against libgsf-gnome-1.so. There are a number of things we can do: 1) leave things the way they are (back to local patching :) 2) apply the patch 3) make a slave port (devel/libgsf-gnome?) 4) make a new port (devel/libgsf-gnome?) depending on devel/libgsf I'll send a patch for option 3 if this is the preferred way. :) sybolt
On Tuesday 09 March 2004 01:05, you wrote: > On Monday 08 March 2004 14:32, you wrote: > > I can see one problem with proposed patch. At the moment main library > > consumers are ports from gnome land. This patch will change package > > configuration built on bento. And we get libgsf package incompatible > > with ports I mentioned before. Pehaps better aproach in this case will > > be creation of slave libgsf-gnome port. > > Just for the record what is the reason you want this option? This list > > will also be usefull for precise dependency targetting if we go the way > > I said. > > Thanks. <...> > Conclusion: of all the ports *explicitly* depending on libgsf, only > gnumeric actually links with the gnome part (libgsf-gnome-1.so), and > gnumeric doesn't need it to build (it does need libgsf-1.so.9). > > Now only if things were so simple! from Mk/bsd.gnome.mk I learned that > USE_GNOME+=libgsf is implied by USE_GNOME+=librsvg2, which is implied by > USE_GNOME+=*who knows what*. Since my computer isn't exactly build-cluster > material, I don't have time/resources to build every single gnome port to > check whether they somehow cheat and link against libgsf-gnome-1.so. > > There are a number of things we can do: > 1) leave things the way they are (back to local patching :) > 2) apply the patch > 3) make a slave port (devel/libgsf-gnome?) > 4) make a new port (devel/libgsf-gnome?) depending on devel/libgsf > > I'll send a patch for option 3 if this is the preferred way. :) I lied. Here are patches for option 4. :) I think it's more correct than option 3. BTW, this is also the way the debian people handle this. Although most ports which use USE_GNOME+=libgsf don't need libgsf-gnome, the patch to bsd.gnome.mk is there for consistency and POLA. The net result of this is: 1) USE_GNOME+=libgsf wroks exactly like it did before 2) ports that only need libgsf can just LIB_DEPENDS on it, without building large parts of gnome. sybolt
State Changed From-To: open->closed Thank you. I committed a solution similar to your latest patch, based on your work.