[oe] [RFD] increased dependency checking

[Frans Meulenbroeks]

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.