Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule

On 16/07/2012 05:22, Jeremy Messenger wrote:
> It's one of reason why I do not agree to remove the shared library
> version from the LIB_DEPENDS, so that way in future someone can add
> support in the package to check on shared library version then prevent
> package to install because it's not ABI compatible. Unless someone
> prefer to do it in the different way than putting shared library
> version in the LIB_DEPENDS is good to me either.

Two points here:

Firstly LIB_DEPENDS is all about *building* packages.  In that case, the
thing that matters is *API* compatibility, not ABI.  Library APIs tend
to be much more stable than ABIs, meaning you can compile your code
against practically any version of a shared library. However, you won't
be able to run your compiled program against a shared library with a
different ABI.  If the API does change incompatibly, then it is fine to
use constraints on the ABI version in a port, but doing this as a matter
of course is just being obstructive to people that may not want to
upgrade dependency shlibs just yet.

Secondly, the ABI version of shared libraries has no effect on the
current dependency resolution mechanisms when installing packages
(either pkgng or the old pkg_tools).  At the moment, the only thing that
is considered are package version numbers.

This is an area where we have plans for dramatic changes with pkgng.  We
want to import a general solver mechanism so that a package can have a
list of generic requirements:

     File /usr/local/bin/foo exists and is executable
     Shared library libfoo.so.3 is installed
     Perl Module Foo::Bar > 1.23 is available
     Package foo-0.99 has option BLURFL enabled
     etc. etc.

Packages will similarly have a list of facilities they provide.  The job
of the solver will be to find a set of packages such that there is a
provider for every requirement constrained by the user requirement that
their required package set is installed.

However, making this mechanism workable implies significant changes to
the ports -- introducing sub-packages in particular -- which are
basically incompatible with the existing pkg_tools.  So we need to pkgng
1.0 in place to be able to proceed with further changes.  Also a generic
solver is in itself a substantial piece of code to introduce.  Which is
why it hasn't happened yet.

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey