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/[email protected]/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, > _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
