Am 15.08.2014 um 14:43 schrieb Karl Pielorz:
>
>
> --On 15 August 2014 12:52 +0200 Łukasz Wąsikowski
> wrote:
>
>> You could solve this by using your own poudriere - create repos with
>> your own port's options and pkg upgrade everything. Your current
>> approach - mixing packages and ports - i
--On 15 August 2014 15:59 +0200 Michael Gmelin wrote:
If it's only about two or three ports and those are leave ports (things
like nginx), mixing pkg and ports works ok in practice.
This is currently the easiest option for us - I was hoping to install the
ports, and just do 'pkg lock' to l
> On 15 Aug 2014, at 14:43, Karl Pielorz wrote:
>
>
>
> --On 15 August 2014 12:52 +0200 Łukasz Wąsikowski
> wrote:
>
>> You could solve this by using your own poudriere - create repos with
>> your own port's options and pkg upgrade everything. Your current
>> approach - mixing packages and
By letting 'pkg upgrade' complete, then running 'pkg info --all -d' I was
able to find out what package upgrade now requires an additional package
"to be INSTALLED".
(In our case memcached-1.4.20_2 pkg now requires cyrus-sasl-2.1.26_8 -
where as it didn't before).
I still can't figure out
--On 15 August 2014 12:52 +0200 Łukasz Wąsikowski
wrote:
You could solve this by using your own poudriere - create repos with
your own port's options and pkg upgrade everything. Your current
approach - mixing packages and ports - is not supported IIRC.
Thanks for the suggestion - and I ta
W dniu 2014-08-13 o 11:45, Karl Pielorz pisze:
> We have a number of 10.x systems now - where we install packages (aka
> pkg install) some components, but other components we build from ports
> (as we need to add / remove options that the package gives you no choice
> over).
>
> Initially 'pkg up
Hi,
We have a number of 10.x systems now - where we install packages (aka pkg
install) some components, but other components we build from ports (as we
need to add / remove options that the package gives you no choice over).
Initially 'pkg upgrade' wanted to replace the port versions with pk