We have made exceptions in the past for exactly the reasons you outline. Unfortunately I know at least for OpenSSL when we have done so on at least one occasion we have been bitten by compatibility

If upstream claims j->k release to just have CVE changesets may be its not a problem, however if there are more fixes that comes along with CVEs then we need to understand closely what these fixes are

Nobody? Andreas

Yocto seems to have a policy not to update packages once a release is generally available. I think that rule should be broken for certain packages that have been reviewed and tested properly. See:

I did write up the specifics of the implementation details into the main commit message for the change. For layer maintainers, the key piece were these points: * Recipes may fail with missing

Thanks, Richard! Will there be some sort of write-up detailing any work required for other layers to adapt to this change? Thanks. -- Denys

Agreed, that's even better. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no

I tend to agree with the expanded "package", I keep reading "PS" as any number of random things ... including "professional services". Cheers, Bruce -- "Thou shalt not follow the NULL pointer, for

PACKAGE_SCRIPTS_DEPENDS maps better to what they are intended to be used for, I think. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br

Looking at this description, it is not at all clear to me why the variable is named PACKAGE_WRITE_DEPENDS. From the description, the things listed in it are dependencies of do_rootfs, not

I agree with stripping out the task piece, I was planning to work something out with that. We could do with this cleanup in other places too. Not all have the form -native (we have some -cross) and I

or PS_DEPENDS with the manual defining PS and users thinking that it means any of: Package Script / Populate Sysroot / Post Script Also, all of Jussi's package changes are of the form:

<jussi.kukkonen@...> wrote: What about DEPENDS_PKG_SCRIPTS ? -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile:

Richard asked me to test this and look at the remaining unhandled postinstalls. I've now done that, patches for the missing PACKAGE_WRITE_DEPS are in the "jku/wip-rss" branch in poky-contrib

Yes, there is. do_some_task[depends] += "some-recipe:some_other_task". DEPENDS is just a neat way of setting [depends] on do_configure to the list of recipes in DEPENDS's do_populate_sysroot

http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/wip-rss I've been quiet on this for a while but the patches are progressing and I've been keeping this branch updated. Its proving a

... Is there not already a mechanism for generically saying "I need <this> task of <that> recipe to be completed before my <such-and-such> task can run" of which DEPENDS and RDEPENDS are simply

Is the testing process for OE patches formalized? I'm not referring to the Yocto Project's release testing.

The sysroot requirements are actually quite varied. It really helps to think about this from a task perspective which is how bitbake really works. In order to run do_fetch, there could be tools like

I was wrong about this - the collection name is collected and used in the dependency resolution. New layers / branches should have this information populated, however we haven't collected collection