On Wed, Mar 16, 2005 at 12:28:45AM -0800, Jeremy Huddleston wrote:
> and I'm glad to be getting paid to do
> Gentoo development.
You lucky bastard... :)
> One problem the Gen-UX project is facing is related to dependency
> tracking. We need to know what libs are on the users system on a binary
> level, not a source level. For instance, if an ebuild depends on
> >=mysql-3, then we need to have a version linked against mysql-3 and
> another against mysql-4 available for the user to download.
Offhand, an alternative is locking the rdepend of a binpkg down to the
specific version it was compiled against. This has other issues (lock
it down, suddenly N versions of a binpkg are required and the rdepend
is *too* accurate).
> Unaddressed
> -------------
> This document does not address other issues associated with
> portage-created
> binary packages including, but not limited to:
> 1. Differences in glibc resulting from different linux-headers
> 2. Differences resulting from different versions of scripting
> languages (perl/python/tcl) existing on the system.
> 3. Differences resulting from different versions/profiles of binutils
> and gcc being utilized as well as differences in CFLAGS, etc.
Also doesn't track dlopens (kdelibs abuse the hell out of dlopen).
> readelf -d <elf> | egrep
> '\((SONAME|NEEDED)\)' can be used for now, but there's probably a
> better
> utility that I'm not thinking of right now.
Marius ^^^ ? You'd mentioned that rpm had a rather
slick/comprehensive approach to this...
>
> This can also help speedup revdep-rebuild by not having it scan the
> users hard drive.
>
> Portage 2.x (/var/db)
> ~~~~~~~~~~~~~
> For portage 2.x, I propose adding two files (soname.DEPEND and
> soname.PROVIDE) to the /var/db/pkg layout which lists these data. We
> can either list the sonames provided/depended for the package as a
> whole
> or we can do it for each file in the package. The latter gives us more
> information and can be easily integrated into version 3.0, so I figure
> the wasted space now will be worth it in the long run.
>
> /var/db/pkg/${CATEGORY}/${PF}/soname.DEPEND:
> <soname> <file requiring soname on system>
> <soname> <file requiring soname on system>
> <soname> <file requiring soname on system>
> ...
Technically it's RDEPEND (not required to merge it, but required to
use it).
> /var/db/pkg/${CATEGORY}/${PF}/soname.PROVIDE:
> <soname> <file providing soname to system>
> <soname> <file providing soname to system>
> <soname> <file providing soname to system>
> ...
>
> Portage 3.0 (Database Layout)
> ~~~~~~~~~~~~~
> pkg_table: (to replace /usr/portage/metadata)
> int pkg_id
> string pkg_name
> string pkg_ver
> <other data currently in /usr/portage/metadata such as DEPEND, etc>
Elaborate on pkg_name and pkg_ver... sidenote, doesn't replace
/usr/portage/metadata (unless you're stating it's single file db),
it's an addition of metadata keys, throughout the tree.
>
> binpkg_table: (to replace /var/db/pkg)
> int binpkg_id
> int pkg_id
> <data currently in /var/db/pkg such as CONTENTS, etc>
>
> soname_table:
> int soname_id
> string soname
>
> contents_table:
> int file_id
> int binpkg_id
> string filename
> <md5sum, filesize, file type, etc>
>
> binpkg_lib_provide_table:
> int provide_id
> int soname_id
> int file_id
>
> binpkg_lib_dep_table:
> int dep_id
> int soname_id
> int file_id
>
> pkg_table lists all packages in portage
>
> binpkg_table lists all packages emerged on the system.
>
> soname_table lists all sonames we know about (they get added
> automatically as portage encounters new ones)
>
> contents_table is designed to replace the CONTENTS file in /var/db and
> is included for completeness wrt the following two tables.
>
> binpkg_lib_provide_table maintains relationships between the package
> installed on the user's system and the soname of libraries it provides.
>
> binpkg_lib_dep_table similarly maintains a relationship for its
> dependencies
I assume everything above is an actual rdbms implementation, not the
existing flat file approach?
Examples would be useful to wrap the skull around this. Base issue I
understand, bincompat/cdepend is being kicked around to address it at
the source pkg level, binpkg level is another thing (not solved by the
bincompat/cdepend approach).
~brian
--
[email protected] mailing list
