Stefano Bennati

@pombredanne I attach the false positives from a bunch of HERE curations, as produced by @PatteSI 's script. Hope this helps, [falsepositives.txt](https://github.com/nexB/scancode-toolkit/files/8196756/falsepositives.txt)

We have a project where ~20 packages are mistakenly identified as projects, I'm not even sure how to solve these issues using curations. A proper fix is likely too far...

@mnonnenmacher sure, let's take an example directory structure like the following: ``` project_root/ |--- lib_dependency/ |--- app/ |--- pubspec.yaml ``` And `pubspec.yaml` contains the following ``` dependencies: here_lib_dependency: path: ../lib_dependency...

Let me revise my example: ``` project_root: |--- app: |--- dependency: |--- pubspec.yaml |--- code: |--- pubspec.yaml ``` `app/code/pubspec.yaml` contains: ``` name: here_code dependencies: here_dependency: path: ../dependency ``` `app/dependency/pubspec.yaml` contains:...

https://github.com/oss-review-toolkit/ort/commit/cea7f66ea43c4ca61cebbed2835d5681acd8d03a breaks this patch. I would like clarity on whether this contribution is actually wanted before spending time to adapt it.

@mnonnenmacher that sounds a good approach. Given that I won't have time to work on this anytime soon either, could we go for this approach and then revert it once...

The reason why I removed duplicate projects instead of duplicate packages is that the correct name for the dependency is specified in `pubspec.yaml`, while the name of the corresponding project...

> If the name is set correctly project and packages should have the same identifier The issue I was facing what that the name specified in `pubspec.yml` was correctly assigned...

Thanks, please go ahead

No, we can close this