[oe] [RFC] Moving old broken EFL stuff to obsoleted Was: [oe-commits] Koen Kooi : efl: bump SRCREV for comp fixes

[Martin Jansa]

Hi,
based on "removing recipes" policy:
http://wiki.openembedded.net/index.php/Upgrading_packages

Has moving to obsoleted as strict rules as removing? I expect that
many builders have obsoleted directory outside BBMASK and thus
ignoring that.

Today I asked for include that patch I pushed to oe.dev for epsilon
build on #edevelop.

16:33:46 < k-s> JaMa: epsilon is dead, avoid it
16:33:56 < k-s> JaMa: it's not about just compile errors, but structural errors
16:34:19 < k-s> i know distros tend to like to keep cruft because "it
is already there", but in this case, just drop it
16:36:04 < k-s> canola is known to depend on it and etk, but at least
epsilon there is a patch to replace it with ethumb
16:38:41 < k-s> well, replacing with ethumb should be simple
16:38:43 < k-s> the apis are similar
16:40:57 < JaMa> k-s:
http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg03583.html
16:41:50 < JaMa> k-s: that omview in particular wasn't touched for
ages and I'm not in touch with previous developer.. so I was hoping
for simple patch for epsilon or drop omview
16:42:24 < k-s> drop omview
16:42:38 < k-s> okra was changing ephoto to be more embedded-friendly
16:42:53 < k-s> JaMa: you may want to ask okra some help and replace
omview with ephoto

EFL is developing pretty fast and avoiding bumping EFL_SRCREV because
some old cruft nobody is using anymore is really pity.

I understand that checking if something is used somewhere is damn hard
to check - for distros outside tree as policy also says.

What's the right compromise?

(I personally tend to like removal as nobody can already check all
versions agains all versions while building world)

Kind regards,

>> efl: bump SRCREV for comp fixes
>> -EFL_SRCREV ?= "45765"
>> +EFL_SRCREV ?= "45902"
>
> With this revision epsilon started to fail (python-epsilon was failing
> before too).
> http://tinderbox.openembedded.net/packages/epsilon/
> http://tinderbox.openembedded.net/packages/python-epsilon/
>
> I asked upstream devs on #edevel for simple fix and they said, that
> epsilon is so unsupported that they would rather move it from OLD/ to
> BROKEN/.
>
> What's right way to handle that in OE?
> Is it worth maintaining epsilon alive in oe.dev and asking upstream to
> include patches for epsilon or can we move epsilon + apps depending on
> it to obsoleted?
>
> We cannot bump ecore, because of epsilon which is pity. If we move
> epsilon to recipes/obsoleted then there is few apps still using that:
> e17/exhibit_svn.bb:DEPENDS = "evas ecore epsilon edje eet etk efreet"
> efl1/epdf/fix-plugin-path-check.patch:    requirements="$requirements
> epsilon imlib2"
> efl1/epsilon_svn.bb:FILES_${PN}-thumbd = "${bindir}/epsilon
> ${bindir}/epsilon_thumbd"
> efl1/esmart_svn.bb:DEPENDS = "evas ecore edje imlib2 epsilon libtool"
> efl1/ewl_svn.bb:DEPENDS = "evas ecore edje emotion efreet epsilon"
> omview/omview_svn.bb:DEPENDS += " evas ewl epsilon"
> python/python-epsilon_svn.bb:DEPENDS += "epsilon python-ecore"
> tasks/task-efl.bb:  epsilon \
> tasks/task-openmoko-feed.bb:  eet evas ecore embryo epsilon edje
> efreet emotion epdf \
> tasks/task-python-efl-examples.bb:  python-epsilon-examples \
> tasks/task-python-efl.bb:  python-epsilon \
>
> Regards,
>