Subject: Re: Inconsistent dependency handling
To: NetBSD Packages Technical Discussion List <tech-pkg@NetBSD.org>
From: Greg A. Woods <woods@weird.com>
List: tech-pkg
Date: 05/23/2006 16:37:26
--pgp-sign-Multipart_Tue_May_23_16:31:33_2006-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
At Tue, 23 May 2006 14:51:01 +0200,
joerg@britannica.bec.de wrote:
>=20
> currently pkgsrc source builds and pkg_add usage can differ in the
> version of packages to use.
>=20
> When doing source builds on a clean system the location part of a
> dependency determines, which package gets installed. So when a package
> requests php>=3D4.4.1nb3, the system recurses into www/php4 and installs
> whatever is available there. pkg_add on the other hand determines the
> *latest* version of package php to fullfil this requirement, so when
> both php4 and php5 are available php5 would get selected.
I've noted this same issue myself in other situations as well even when
just selectively building packages and trying to ensure that all the
necessary packages are in one's pkgchk.conf. In these situations it
seems particularly troublesome with interpreters and the like.
The issue seems to stem from the way newer versions of compatible
dependents are put into named directories in pkgsrc, and from the way
the DEPENDS lines are specified with a specific pkgsrc directory to
build from.
My blue-sky thought of an ideal solution was something like getting rid
of the pkgsrc directories from the DEPENDS line entirely and using
information from the INDEX file, plus perhaps some local policy
specifications that would allow a direction to be chosen when multiple
dependents would satisfy the requirements. This would maybe allow
pkgsrc as a whole to make the same kinds of global decisions that
pkg_add does since with the whole INDEX file one doesn't have to dive
into any specific directory before making the choice of which version of
a dependent will be built.
Sadly generating the INDEX file is painful, especially for the fast
moving target of the trunk and lack of any local fast system.
> IMO it is an error when the latest version of a package doesn't come
> from package directory specified in the dependency line, so all PHP 4.4
> dependencies should be changed to explicitly specify < 5 like we do in
> pkgsrc-security for vulnerabilities.
Yes, that seems like it would work OK, at least for things where there
are forward compatibility issues. It doesn't seem to make sense though
in general where there are more complex compatability changes in a
dependent, or even where there are no forward compatibility issues.
The real problem still seems to stem from the fact that multiple pkgsrc
directories can contain what's essentially the same core dependent
package, just with different major variations, and so the DEPENDS lines
have to choose between these directories.
> This can break custom updates
> though, but I think those should be named with a different prefix.
I'm not sure what you mean by that.
--=20
Greg A. Woods
H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Secrets of the Weird <woods@weird.com>
--pgp-sign-Multipart_Tue_May_23_16:31:33_2006-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: AkFARKyYwom3GedA/A+fzz72oMjynUTX
iQA/AwUBRHNxSmJ7XxTCWceFEQI8GQCgzoKkiPJ3bCGWj+8A+T+ysvt0xN4AnilB
A3KIHrVmTuJlFoncAoOl156Q
=nvy6
-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Tue_May_23_16:31:33_2006-1--