On 09/06/14 12:18, Ciaran McCreesh wrote:
Well eix is buggy, PMS-violating and doesn't support EAPIs properly,
and the utilities in gentoolkit and portage-utils are better implemented
natively in a package manager. I don't know what elfix does, but if
it's anything like the other three, I'd rather reimplement it in a PMS
compliant manner for Paludis than to provide flaky external APIs that
encourage people to write broken code...
elfix contains revdep-pax which does what revdep-rebuild does, except
that it migrates PaX flags from executables to libraries and vice versa.
There exists a category of tools that can make use of PM's cached
information which should not be part of PM. elfix is one such example.
Let me give you another:
https://bugs.gentoo.org/show_bug.cgi?id=506276#c42. That bug is about
removing SYMLINK_LIB=yes. To do so properly and migrate systems that
use symlinks for /libXX, vapier wrote a migration script which at one
point "walk[s] the vdb looking for files that installed into /lib32 and
/lib."
These sorts of utilites pop up over and over again. You cannot put
every utility that needs package information into a package manager. An
API for interoperability between PM's and other tools is meaningful.
Refusing to do so leads to the sort of comment you see in
https://bugs.gentoo.org/show_bug.cgi?id=506276#c43.
Ironically, the very standards I seek in GLEP 64 would benefit the
paludis world most.
When the package is installed, that data should have been cached.
But package.provided packages *aren't* installed. They are merely
treated as if they were installed, without actually being installed, so
that data isn't available.
Right. hasufell's email made it clear. This is pretty hacky so we
don't want to go there.
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : bluen...@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
