On 21/08/2013 09:45, Marko Cupać wrote:
> I am building www/dansguardian in poudriere, and it always builds
> www/squid (squid-2.7.X) as a dependency, even though I have already
> built www/squid33 (squid-3.3.x).
>
> I guess it is related to the following Makefile line:
> RUN_DEPENDS= ${LOCALBASE}/sbin/squid:${PORTSDIR}/www/squid
>
> So, on systems which already have www/squid33 installed, it sees
> ${LOCALBASE}/sbin/squid and does not build squid27. But in poudriere
> there isn't ${LOCALBASE}/sbin/squid so it builds ${PORTSDIR}/www/squid.
>
> I guess I could edit Makefile line like this:
> RUN_DEPENDS= ${LOCALBASE}/sbin/squid:${PORTSDIR}/www/squid33
>
> to make it work, but it would be overwritten on next revision. Is it
> possible to find a solution (e.g. by means of choosing squid version
> in configure options) for official port Makefile? Or switch to latest
> squid by default?
This is one of a general class of problems we tend to run into with
compiled pkgs which is a deficiency compared to the way it works when
installing by compiling from ports.
A dependency line like:
RUN_DEPENDS= ${LOCALBASE}/sbin/squid:${PORTSDIR}/www/squid
will be satisfied if any file ${LOCALBASE}/sbin/squid exists. The port
name only exists as a hint to the ports system about what to install if
that squid executable is not available.
With pre-compiled pkgs, dependencies are expressed as being on some
other specific package, and this relation is 'baked in' to the pkg.
Unless there is some means of substituting a different dependency
package via the ports system, as there is for eg. emacs or apache or
mysql, then you'ld have to jump through hoops to make pkg produce
packages that will let you mix squid33 with dansguardian.
Two possible approaches:
i) As you suggest, edit the dansguardian Makefile and customize
the RUN_DEPENDS line. Which is probably the easiest solution
overall, but it only applies if you've got your own poudriere setup
or equivalent, and you will have to maintain your own set of
patches to the ports tree
ii) Delete squid33, and install the dansguardian package allowing it to
pull in the other squid package as a dependency. Then use
'pkg set' to override the dependency relationship, and force a
reinstall to get the version of squid you require. (Untested,
but something like this:)
pkg delete squid33
pkg install dansguardian
pkg set -o www/squid:www/squid33
pkg install -Rf www/squid33
You can use a public repo and the default packages from it with
this strategy, but you will likely have to repeat this sort of
process whenever there are updates to packages in that dependency
sub-tree.
Ultimately we are intending to solve this sort of problem by switching
to a general 'REQUIRES / PROVIDES / CONFLICTS' set of dependency
variables[*], and importing a more sophisticated package solver. Work
on that is underway at the moment, but getting it into production is
going to involve some ... interesting ... changes in the ports tree, so
it's not going to happen for quite a while yet.
Cheers,
Matthew
[*] So the dansguardian port would say inter-alia something like:
REQUIRES+= executable:squid
and the various www/squid* ports would have
PROVIDES+= executable:squid
(except that probably won't need to be specified explicitly in the
port Makefile, as it can be inferred from the pkg-plist when a
squid port is installed. Oh, and the actual syntax for PRC
probably won't be anything like that at all)
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
