media-libs/lcms: Remove unbuildable package due to py27 dep #191

python2_7 is now unsupported.

 * ERROR: media-libs/lcms-1.19-r1::trinity-official failed (depend phase):
 *   No supported implementation in PYTHON_COMPAT.
 * 
 * Call stack:
 *                ebuild.sh, line 609:  Called source 'tde-packaging-gentoo/media-libs/lcms/lcms-1.19-r1.ebuild'
 *      lcms-1.19-r1.ebuild, line   8:  Called inherit 'autotools' 'eutils' 'python-r1'
 *                ebuild.sh, line 314:  Called __qa_source '/usr/portage/eclass/python-r1.eclass'
 *                ebuild.sh, line 112:  Called source '/usr/portage/eclass/python-r1.eclass'
 *         python-r1.eclass, line 260:  Called _python_set_globals
 *         python-r1.eclass, line 199:  Called _python_set_impls
 *   python-utils-r1.eclass, line 156:  Called die
 * The specific snippet of code:
 *                      die "No supported implementation in PYTHON_COMPAT."
 * 
 * If you need support, post the output of `emerge --info '=media-libs/lcms-1.19-r1::trinity-official'`,
 * the complete build log and the output of `emerge -pqv '=media-libs/lcms-1.19-r1::trinity-official'`.
 * Working directory: '/usr/lib/python3.9/site-packages'
 * S: '/var/tmp/portage/media-libs/lcms-1.19-r1/work/lcms-1.19'

Hmm, don't remove this package as it is required for other packages. You just need to remove Python support from this package.
I have never used python support in my assemblies before, so I have no problems building this package. See here. Although this package is only needed for koffice.

Disabling python 2.x support instead of removing the ebuild seems a better option for the moment. In addition to koffice lcm1, it is also needed for digikam.

That's a possibility, but neither package is available in the overlay. trinity-base/ksvg is the only revdep as far as I can see.

That's a possibility, but neither package is available in the overlay.

Yes, of course, but this does not mean that later koffice will not be added.

trinity-base/ksvg is the only revdep as far as I can see.

For trinity-base/ksvg everything is correct, media-libs/lcms:2 is needed.

I also think that, since we already have it, lcms:0 should be retained for now with python support disabled (which, from the look of it, will result in a much smaller ebuild). We can remove it once either koffice and digikam are moved to lcms:2, or it becomes obvious that neither package will ever make it into the overlay.

Moving ksvg to lcms:2 is perfectly reasonable, though—better to use the modern library if at all possible.

I think we can merge so as not to wait long. Then I can rebase and re-add that package when I add koffice. Already implemented the trinity-apps/chalk assembly, with the lcms1 dependency. I had to fix the tqt build parameters to make chalk work.
I think in a week or two, I will already do a PR, but for this I already need to solve something with lcms1.

No need to, I can change it.

I just hope there is some effort upstream to port those applications away from lcms1.

I just hope there is some effort upstream to port those applications away from lcms1.

It wouldn't be bad, but I haven't seen any progress in this area yet. For now, I think it's worth making the implementation of the koffice assembly. Therefore, a working lcms1 is still needed.
It seems like it has long been suggested to transfer chalk to lcms2, but no one has yet undertaken this work. For now, I'll add the implementation of the koffice assembly, for later inclusion in stable assemblies.

So... what's the consensus? It's an easy one to fix either way: to remove the python support or lcms1 at all... and the portage complains during dependency calculation are quite annoying...

Therefore, I proposed to merge this PR. lcms1 can be added back along with the koffice. In any case, chalk won't work without lcms1. It will not work well if I add koffice, and the lcms1 ebuild will not work.

As far as I know, lcms1 is also needed for digikam. Ebuild for digikam not yet available?

For me, it would seem more handy to remove python2 support from an existing ebuild for lcms1 than to remove the whole ebuild and then return the ebuild soon.

Ebuild for digikam not yet available?

This ebuild is not yet available.

For me, it would seem more handy to remove python2 support from an existing ebuild for lcms1 than to remove the whole ebuild and then return the ebuild soon.

Unfortunately, this ebuild is broken at the moment and needs to be fixed. It's just that as soon as the ebuild is removed I can rebase for koffice. After that I will add the ebuild there.

Ok, so the easiest way for the moment seems to be to merge this PR.