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

On Mon, Jul 16, 2012 at 2:24 AM, Matthew Seaman <matthew_at_freebsd.org> wrote:
> 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.

I know. Hences for the 'in future someone can add support'.

Cheers,
Mezz

> 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


-- 
mezz.freebsd_at_gmail.com - mezz_at_FreeBSD.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gnome_at_FreeBSD.org