> > 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).
ah... stupid KDE. Thanks for pointing this out... I wonder if we could
do something clever to figure that stuff out... hrm...
> > /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).
Well I wasn't really associating this with RDEPEND or PDEPEND...
> > 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.
Actually, this was meant to hopefully integrate with the current 3.0
layout (where is that by the way?) So, we probably need a
category_table or something like that. pkg_name would be the package
name ("glibc" for example). pkg_ver would be the version string
("2.3.4.20050125-r1" for example).
> > 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?
That was my understanding of what 3.0 was going to accomplish, so that
was the idea behind this...
> 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).
what's the bincompat/cdepend approach?
signature.asc
Description: This is a digitally signed message part
