This is needed to build software i.e. ScummVM. This is the first ebuild that disables this without any need. 2.8 and 2.9 dont disable that option.
This is intended and also done upstream. Software building against freetype should use pkg-config, not freetype-config. File specific bugs about specific software still using freetype-config and make it blocking bug 654792; well, if one doesn't exist already there on depend line :)
This has nothing to do with building software from the Gentoo repos. Besides upstream made it optional to build freetype-config not disabling it outright what Gentoo has done.
Ok, assigning to maintainer for a final verdict with non-repository compiling considered
freetype-config will not come back. *** This bug has been marked as a duplicate of bug 654792 ***
Is there a reason for this?
(In reply to farmboy0 from comment #5) > Is there a reason for this? Yes, freetype-config is deprecated and not cross-compile safe. Now that upstream finally no longer installs freetype-config by default, we are just following what upstream's intention is.
Upstream provides a configure switch. Gentoo supports these in the form of USE flags. Please add a USE flag for this until all in-tree packages have been adapted? Right now, portage will simply downgrade to an old freetype version which has some unfixed bugs, because ebuilds need to depend on old versions. If you add a USE flag (disabled by default), ebuilds can instead depend on the USE flag instead of forcing an old freetype version.
(In reply to Nikos Chantziaras from comment #7) > Upstream provides a configure switch. Gentoo supports these in the form of > USE flags. > > Please add a USE flag for this until all in-tree packages have been adapted? > Right now, portage will simply downgrade to an old freetype version which > has some unfixed bugs, because ebuilds need to depend on old versions. If > you add a USE flag (disabled by default), ebuilds can instead depend on the > USE flag instead of forcing an old freetype version. No, because that would simply give package maintainers an excuse to never fix their packages. Furthermore, once I gonna remove that USE flag again I'd had extra work burden to make sure no package depends on that USE flag anymore.
(In reply to Lars Wendler (Polynomial-C) from comment #8) > No, because that would simply give package maintainers an excuse to never > fix their packages. This hasn't changed. They can simply depend on the previous freetype version. > Furthermore, once I gonna remove that USE flag again I'd had extra work > burden to make sure no package depends on that USE flag anymore. I think the best way here would have been to mask the USE flag instead of removing it. The polite steps to remove something is to deprecate it, mask it, finally remove it. Currently the only people "punished" here are users, not package maintainers. So I'd say the plan has failed :-P
Welcome to ~arch... that said, I find the transitioning done in a way that delays a security stabilization rather concerning here. Otherwise I fully support the freetype-config removal. The security fix should be backported or a revision that ships freetype-config (and always enables it) stabilized for security, with the removal of freetype-config continuing in its own pace in ~arch in a higher revision or version than one that puts it back for security stabilization.
(In reply to Mart Raudsepp from comment #10) > Welcome to ~arch... I don't understand the rationale of not masking the USE flag prior to removing it. What is the issue?
