On 09/06/14 09:10, Ciaran McCreesh wrote:
On Sat, 06 Sep 2014 09:03:13 -0400
"Anthony G. Basile" <bluen...@gentoo.org> wrote:
Note that, as with the Metadata Cache, these variable should be stored
with all the conditionals evaluated.
Paludis doesn't do this (and historically, Portage didn't either). We
store USE etc. This is useful because it allows us to detect when
people have been mucking around with DEPEND and the like.
This was a suggestion from mgorny and I trust his opinion on the
matter. It does make sense to have metadata catche which is
conditionally evaluated be exported. If PM's also want to the
conditionals in there, there is nothing in the GLEP which prevents it.
A list of all files belonging to the package, along with a designation
of the file type (regular, directory, symlink, pipe, etc), MD5SUM or
other checksum, and mtime time.
Packages aren't allowed to install pipes.
Okay I will remove pipes. Do you have a reference btw about what types
of files can be installed.
A list of all executable or shared objects for each package and the
corresponding linking information, including full path to the object,
its architecture and ABI, SONAME, RPATH and any NEEDED objects they
link against, as reported by `readelf` on ELF systems, or similar
tools for other executable formats. Currently this information is
being cached by Portage in NEEDED.ELF.2, NEEDED.MACHO.3, NEEDED.XCOFF,
NEEDED.PECOFF, etc.
This is utterly arbitrary, and introduces a dependency on particular
non-standard package whose behaviour we don't control. Not everything
is C and ELF, and we shouldn't be encouraging "solutions" that make
the assumption that they are...
1) This cannot be utterly arbitrary because there are utilities and
portions of portages code which does make use of precisely this information.
2) With the exception of some embedded systems where everything is
statically linked, all modern systems have dynamic linking. And all
dynamic linking has information in its objects which associates the
executables with the library they link against. This is the essential
information to be stored.
3) You are correct that the bias there is towards ELF. So I will add
language indicating similar information for the other executable formats.
4) Of course not everything is C. (BTW the better example to make your
case, is FFLAGS for fortran which I omitted --- I will add language here
too). The point is to record dynamical linking information where it is
generated. Such information is obtained at build time, is expensive to
regenerate, is useful at a later time for both the PM and other
utilities, and so should be cached. We would record this even for an
executable generated from fortran source, say, that links against some
libraries.
5) For packages which don't have any dynamical linking, we just leave
those things blank. ie. asking for the SONAME of some file
/usr/share/pkgconfig/ returns null with some error.
6) Without a standard here, we have utilites which make use of this
cached information in the tree which only work with portage but not
paludis. This problem can be solved by removing those utilities, which
is undesireable, by standardizing what needs to be exported from the PM,
or by living with the status quo which is having useful packages in the
tree which don't work with paludis.
You've also not discussed how this interacts with Portage's
package.provided misfeature.
Finally, you don't have any way of using this information, since you
don't have a way of knowing what packages are installed.
I don't understand your reasoning behind these points, can you please
explain.
--
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
