I will not go into the accusations and incorrectnesses in the posts above. The only thing I'll say about it on this nice sunday morning is:
Let him who is without sin cast the first stone (Gospel of John chapter 8 verse 7) There is another thread on the removal of recipes. Please take your gripes there and do not hijack all kind of topics by bringing this up. And back to the original topic: Actually despite what some people may think I do understand the openssl issue. The reason I raised it was to actually get to rebuild of the recipes that are affected by a change within a recipe that would break requiring packages. This can be done by a PR bump of all users, but our depends are far from complete and (apart from grep xyz recipes/*/*) there is not really a way to find out who uses a recipe. (and that grep is quite cumbersome if e.g. you want to find out who depends on popular or short names). I was unaware of the BB_STAMP_POLICY (and haven't found docs about it yet). That seems to resolve the openssl issue (at least in a local build). An alternative could be a flag in a bb file that indicates it as vulnerable so we could have a different policy behaviour for those recipes. I am quite aware that packet management brings additional complications. If you rebuild the package then at least the new package depends on the new lib so everyone getting the new version gets the new lib. And the package installer could just keep the old lib adjacent to the new lib. That is not so strange. On the system I am typing this I have e.g. /lib/libreadline.so.5 /lib/libreadline.so.5.2 /lib/libreadline.so.6 /lib/libreadline.so.6.0 That way I feel a migration from one lib to another could go quite smoothly. An alternative solution could be to not only look at the version but also at the time a package is created (so if a version shows up with a newer timestamp it is upgraded). With the above rebuild strategy that could also work. (and yes: I know this also has some con's). Or we could explictly give recipes that produce libraries with a different SONAME in a differently named recipe (e.g. with the soname in the PN part and not in PV. (and yes, that most likely has some package manager impact too). I have no idea on what the best solution is. That is also why i started this thread (to deal with the first step in it). The only thing I am sure of is that the current solution has some weaknesses (as clearly indicated by the openssl issue), and we should try to improve that. One way to achieve that is to have an open and constructive discussion on it. In such a discussion there will always be bright ideas and less-than-bright ideas, but at least such a discussion may separate the wheat from the chaff and lead to improvement. Have a nice day! Frans. _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
