It looks like Portage now stores unicode paths correctly in its metadata
as opposed to what it used to be. We need to make sure that we parse those
"CONTENTS" file and content metadata in general using the correct encoding.
This will allow us to store and retrieve such metadata from the sqlite3
database correctly and also match the stored paths with the filesystem
paths exactly.
This commit may need a bit more real-life testing. Backward compat
wrt old Entropy and Portage tbz2 files should be as expected.
Unit tests attached.
Historically, Portage + Py2 were not dealing well with file paths that
were containing non-ascii chars. The situation has apparently improved
and we are able to accept paths with the correct encoding in Entropy
(separate patch will come). We need to guard against broken paths anyway,
so let's try to check which one of the paths is the one that has the
most chance to be the right one. Also, with python3 this won't be
a problem anymore...
Due to the migration to real virtual packages (away from PROVIDE= due
to EAPI=7 constraints), we failed to resolve kernel binary packages
correctly, thus packages that require them (external kernel modules.)
This patch fixes it, by making sure that we resolve new virtuals correctly.
We expect new virtuals to list kernel packages in their RDEPEND= (runtime
dependecies.)
- Variable entropy_client was not available where it was used.
- Module entropy.dep was not imported but was used. It worked as
the module was imported from another place, but it is better to
import it explicitly.
Suggested by Ettore.
My comment is that it is to have a more correct information and to give
credit where it is due.
This is not a "miscredit" towards the Creator. We know who has made this
possible!
- runs as non-root
- does not require being in entropy/portage group
- in fact, it's better (better isolation) to run as such
- thus does not modify running system
The wrapper script is ugly but very convenient.
