This thread [1] on the gentoo.user mailing-list, where someone complained about missing tkinter support in scribus led me to [2], where the dependencies of scribus are listed. So maybe a tk use flag in scribus should be implemented, see attached diff to scribus-1.3.4-r1.ebuild. In the attached diff i also updated some dependency versions according to the recommendations there and added media-libs/jpeg as new dependency. There are also other dependencies which the ebuild maybe should take care of, like Postscript-Fonts. Plus other optional dependencies like CUPS development libraries (net-print/cups), Gimp Print development libraries (media-gfx/gimp-print), python-imaging libaries (dev-python/imaging), openssl-devel (dev-libs/openssl), fontconfig-devel (media-libs/fontconfig) and antiword (app-text/antiword) There is another thing i want to know. The ebuild has virtual/ghostscript as dependency. At this site [2] there are Ghostscript 8.15+ or GPL Ghostscript 8.56 highly recommended. Is it true that up to now you can not control the versions of packages which are pulled in by virtuals. This virtual would be satisfied with app-text/ghostscript-gpl-9.54 on my system as 9.57 is still in testing. [1] http://archives.gentoo.org/gentoo-user/msg_114916.xml [2] http://docs.scribus.net/index.php?lang=en&page=install2
Created attachment 125689 [details, diff] Diff for scribus-1.3.4-r1.ebuild
Created attachment 125691 [details, diff] Diff for scribus-1.3.4-r1.ebuild Changed qt dependency too!
tHE BUG IS SIMPLY THAT THE LIB-TK IS MISSING IN THE DISTRIBUTION !
(In reply to comment #3) > tHE BUG IS SIMPLY THAT THE LIB-TK IS MISSING IN THE DISTRIBUTION ! You mean missing in gentoo? What about dev-lang/tk then? Anyway this bug is now more than one year old and there are now other possibilities of adding tk functionality to the ebuild by using eapi2 features. Any comments on the tk use flag and the additional dependencies mentioned in the initial report? While looking at the current ebuild a few recommendations have alrerady been implemented. Hanno, it would be good to get an offical statement so we can discuss and eventually close this bug.
Hi, about the tk stuff, I don't think this is anything we should cope around with use flags. As far as I can see, the flag in your patch just does nothing on the scribus build. use-flags are to change the build process. if there's an additional feature that requires a useflag on another package, this is nothing we need to take care of in the ebuild. For your raised dependencies, I'll apply them (to 1.3.3, the 1.3.4 ebuild is rotten and unsupported anyway), although it's not really needed as all those versions are already stable in portage. The only point though is the dep on jpeg.
correcting me, the raised deps are already in 1.3.3.12.
Created attachment 172758 [details, diff] scribus-1.3.3.12-r2.diff (In reply to comment #5) > Hi, about the tk stuff, I don't think this is anything we should cope around > with use flags. As far as I can see, the flag in your patch just does nothing > on the scribus build. > > use-flags are to change the build process. if there's an additional feature > that requires a useflag on another package, this is nothing we need to take > care of in the ebuild. Haven't built_with_use and nowadays use dependencies been introduced to define such dependencies? Also I wrote this patch more than one year ago when I had not that much experience with ebuilds. The use flag is not needed I just tried to avoid hard coding the dependency on tk in python just for the font sampler script. So either rename the use flag to something else or leave it hard coded. You are right it does nothing to the build process of scribus but it makes sure that the font sampler script is actually usable at runtime. In the scribus-1.3.3.12-r1.ebuild you already depend on dev-python/imaging which is also just needed for that script but this is useless as the the font sampler script needs tk support to be present in python. So there are actually three ways of checking for tk support in python. 1. Use built_with_use to check if the tk flag is enabled and abort if not. pkg_setup() { if ! built_with_use dev-lang/python tk ; then eerror "Please emerge python with useflag 'tk' enabled." die "Fix USE flags and re-emerge" fi } 2. I think this way has been deprecated in favor of using python_tkinter_exists from python.eclass which tries to import the python tkinter module and fails with an error message like above. inherit python pkg_setup() { python_tkinter_exists } or with an use flag (this could be adapted for method 1 and 3 too, I do it here as this is the the option I prefer) inherit python USE="scripts" DEPEND="scripts? ( dev-python/imaging )" pkg_setup() { use scripts && python_tkinter_exists } 3. The easiest way are using use dependencies from eapi 2 but as there is no stable package manager that supports it I do not see this as an option for now. EAPI=2 DEPEND="dev-lang/python[tk]" Also I found out that cups needs to be hard coded as dependency. I uninstalled cups and tried to build with USE="-cups" but scribus fails to configure with messages like this: CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: CUPS_INCLUDE_DIR used as include directory in directory /media/system/tmp/portage/app-office/scribus-1.3.3.12-r1/work/scribus-1.3.3.12 Furthermore cmake-utils_use_enable cups does not work as it calls -DENABLE_CUPS=ON/OFF but there is no such option in CMakelists.txt from the scribus source. The only options for scribus I see is cairo with -DWANT_CAIRO=0/1 or libart with -DWANT_LIBART=0/1 so only use flags like cairo or libart which are blocking each other are making sense here. Plus in the current ebuild disabling cairo use flag doesn't work. cairo? ( >=x11-libs/cairo-1.4.10 )" pkg_setup() { if ! built_with_use 'x11-libs/cairo' 'X' 'svg'; then eerror "You must build cairo with X and svg support" die "x11-libs/cairo built without X and/or svg" fi } Imagine cairo is disabled and thus not present on the system and the ebuild checks if cairo is built with use X and svg anyway, so disabling cairo is impossible.
