Date: Mon, 16 Jul 2012 08:44:05 -0500 From: Jeremy Messenger <mezz.freebsd@gmail.com> To: Matthew Seaman <matthew@freebsd.org> 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: <CADLFttf-GD6wpoojiccSeZbeydeB1gKg2crE3LHNkyTomyzBLg@mail.gmail.com> In-Reply-To: <5003C1C2.1010500@FreeBSD.org> References: <20120712100110.GA34228@ithaqua.etoilebsd.net> <20120716033240.GA52346@server.rulingia.com> <CADLFttfjdfvPPR6WsRcF58pSFVL%2BP2PAGb8NOtLi-vS30jNDhQ@mail.gmail.com> <5003C1C2.1010500@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 16, 2012 at 2:24 AM, Matthew Seaman <matthew@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@gmail.com - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADLFttf-GD6wpoojiccSeZbeydeB1gKg2crE3LHNkyTomyzBLg>