Ok, I don't think this is really GLEP worthy, but I've decided to write out my future design docs in GLEP format just in case it ever reaches that point.
For those who aren't aware, I recently started working for Gen-UX which
is a small startup providing compiled binary packages for Gentoo users.
It is a very ambitious project, and I'm glad to be getting paid to do
Gentoo development.
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.
This document describes a way in which the library sonames provided by
and depended on by a binary package can be stored in the portage
database on a users system for easy access. It also provides another
optimized use for this data in revdep-rebuild.
Any thoughts, suggestions?
--Jeremy
GLEP: ## Unannouned ##
Title: Portage database tracking of binary dependencies by soname
Version: $Revision: $
Last-Modified: $Date: $
Author: Grant Goodyear <[EMAIL PROTECTED]>
Status: Draft
Type: Standards
Content-Type: text/x-rst
Created: 09-March-2005
Post-History:
Overview
=============
Background
-------------
Source code may be source compatible with multiple ABI incompatible
versions of a particular library. An example of this is gimp which can
be compiled and linked against either libpng-1.0 or libpng-1.2. These
libraries have different sonames associated with them, and the linker
sets this soname in the resulting executable. When the executable is
run, the loader uses this soname to select the proper library to load.
Problem
-------------
The problem exists in the inability of portage to track this type of
dependency. Currently, the utility 'revdep-rebuild' is used to scan a
user's system for broken executables and re-emerge broken packages.
Additionally, portage does not check ABI dependencies when installing
binary packages (.tbz2 packages created by quickpkg or 'emerge -b') to
ensure ABI compatibility with the current system.
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.
Proposal
=============
Portage DB (/var/db and eventually in the abstracted DB in 3.0)
-------------
We need to add data to the portage database which lets us query what
binaries rely on what libraries. This data is gathered from the
dynamic
section of the ELF binary. 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.
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>
...
/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>
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
Backwards Compatability
-------------
revdep-rebuild can generate the /var/db entries for packages which were
installed using older versions of portage.
signature.asc
Description: This is a digitally signed message part
