Date: Mon, 16 Jul 2012 08:24:50 +0100 From: Matthew Seaman <matthew@FreeBSD.org> To: Jeremy Messenger <mezz.freebsd@gmail.com> Cc: ports@FreeBSD.org, Baptiste Daroussin <bapt@FreeBSD.org>, Peter Jeremy <peter@rulingia.com>, current@FreeBSD.org Subject: Re: [HEADSUP & CFT] pkg 1.0rc1 and schedule Message-ID: <5003C1C2.1010500@FreeBSD.org> In-Reply-To: <CADLFttfjdfvPPR6WsRcF58pSFVL%2BP2PAGb8NOtLi-vS30jNDhQ@mail.gmail.com> References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <20120716033240.GA52346@server.rulingia.com> <CADLFttfjdfvPPR6WsRcF58pSFVL%2BP2PAGb8NOtLi-vS30jNDhQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB6CCF21792C0CD10410E78F2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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
--=20
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
--------------enigB6CCF21792C0CD10410E78F2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlADwckACgkQ8Mjk52CukIwGwgCeKC62b60sbWQhIRr0dSldwQIK
5XcAn2Ou620h7B6o7gYqgUvcIk6IjQjQ
=QnI0
-----END PGP SIGNATURE-----
--------------enigB6CCF21792C0CD10410E78F2--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5003C1C2.1010500>