Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Mar 2013 12:46:15 -0700 (PDT)
From:      Paul Pathiakis <pathiaki2@yahoo.com>
To:        "ports@freebsd.org" <ports@freebsd.org>
Subject:   Where has all the groupware gone.....
Message-ID:  <1363549575.86830.YahooMailNeo@web141402.mail.bf1.yahoo.com>

next in thread | raw e-mail | index | archive | help
Hi,=0A=0AI have tried building many pieces of groupware so that I can repla=
ce MS at various client sites.=0A=0AHowever:=0A=0Azimbra?=A0 No port.=A0 (H=
ardcoded /opt/zimbra)=0Akolab?=A0 No port.=A0=A0=A0 (Hardcoded /kolab=A0 - =
This could work if they got rid of the idiocy of "OpenPKG")=0A(A kolab port=
 could easily be done if all the dependencies their rpms were made into a p=
ort for it. - It should work fairly easily with ZFS)=0A=0ACitadel?=A0 No po=
rt.=A0 Got it working and seems pretty decent.=0A=0ASimpleGroupware - Not D=
B independent, MySQL only=0ATine?=A0 Not DB independent, MySQL only=A0 (Who=
 does that in this day and age?)=0A=0AHorde?=A0 Port is cumbersome and very=
 few tips anywhere to get it up and running quickly on FreeBSD=A0 (Is there=
 a doc I can't find?)=0AHorde=0A Web?=A0 Same as Horde=0A=0AEgroupware?=A0 =
Sweet... Works nice and seems very useful.=A0 Many compliments from people =
on how well it works.=A0 =0A=0A=0APhpgroupware?=A0 Not really groupware in =
the form of the others above.=0A=0AI'm just evaluating.=A0 I have no affili=
ation with any.=A0 However, the lack thereof when we could be inserting gro=
upware FreeBSD servers in clients... :-)=0A=0AThank you for checking into t=
his and creating real ports and/or documentation.=0A=0AP.=0A
From owner-freebsd-ports@FreeBSD.ORG  Sun Mar 17 20:04:26 2013
Return-Path: <owner-freebsd-ports@FreeBSD.ORG>
Delivered-To: freebsd-ports@freebsd.org
Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115])
 by hub.freebsd.org (Postfix) with ESMTP id 46ADEB16;
 Sun, 17 Mar 2013 20:04:26 +0000 (UTC)
 (envelope-from coco@executive-computing.de)
Received: from mail.moehre.org (mail.moehre.org [195.96.35.7])
 by mx1.freebsd.org (Postfix) with ESMTP id 5963DFEB;
 Sun, 17 Mar 2013 20:04:25 +0000 (UTC)
Received: from mail.moehre.org (unknown [195.96.35.7])
 by mail.moehre.org (Postfix) with ESMTP id 961AC8B143B;
 Sun, 17 Mar 2013 21:04:24 +0100 (CET)
X-Spam-Flag: NO
X-Spam-Score: -100.966
X-Spam-Level: 
X-Spam-Status: No, score=-100.966 tagged_above=-999 required=5
 tests=[ALL_TRUSTED=-1, AWL=0.034, USER_IN_WHITELIST=-100]
 autolearn=disabled
Received: from mail.moehre.org ([195.96.35.7])
 by mail.moehre.org (mail.moehre.org [195.96.35.7]) (amavisd-new, port 10024)
 with ESMTP id 376J8QbiQQR8; Sun, 17 Mar 2013 21:04:22 +0100 (CET)
Received: from [192.168.100.30] (p54B08F18.dip.t-dialin.net [84.176.143.24])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (No client certificate requested)
 (Authenticated sender: coco@executive-computing.de)
 by mail.moehre.org (Postfix) with ESMTPSA id B82BA8B1420;
 Sun, 17 Mar 2013 21:04:22 +0100 (CET)
Message-ID: <5146213E.3080005@executive-computing.de>
Date: Sun, 17 Mar 2013 21:02:06 +0100
From: Marco Steinbach <coco@executive-computing.de>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Baptiste Daroussin <bapt@FreeBSD.org>
Subject: Re: OPTIONSng: Overide options in /var/db/ports/*/options ?
References: <5145B415.80303@executive-computing.de>
 <5145C9DC.6010300@infracaninophile.co.uk>
 <5145E47D.4050201@executive-computing.de>
 <CADLo8399uthkGDPGQv8aV8hdOuBzcsczcdx1tv5KoWAQmCjVFA@mail.gmail.com>
 <51460B2C.6080500@executive-computing.de>
 <20130317184927.GF72627@ithaqua.etoilebsd.net>
In-Reply-To: <20130317184927.GF72627@ithaqua.etoilebsd.net>
Content-Type: multipart/mixed; boundary="------------020101010002080200010000"
Cc: Chris Rees <utisoft@gmail.com>,
 FreeBSD Mailing List <freebsd-ports@freebsd.org>
X-BeenThere: freebsd-ports@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Porting software to FreeBSD <freebsd-ports.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-ports>,
 <mailto:freebsd-ports-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ports>;
List-Post: <mailto:freebsd-ports@freebsd.org>
List-Help: <mailto:freebsd-ports-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ports>,
 <mailto:freebsd-ports-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Mar 2013 20:04:26 -0000

This is a multi-part message in MIME format.
--------------020101010002080200010000
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Baptiste Daroussin wrote on 17.03.2013 19:49:
> On Sun, Mar 17, 2013 at 07:27:56PM +0100, Marco Steinbach wrote:
>> Chris Rees wrote on 17.03.2013 17:15:
>>> On 17 Mar 2013 15:45, "Marco Steinbach" <coco@executive-computing.de> wrote:
>>>> Matthew Seaman wrote on 17.03.2013 14:49:
>>>>
>>>>> On 17/03/2013 12:16, Marco Steinbach wrote:
>>>>>> Hi,
>>>>>>
>>>>>> is there a way to overide options stored in /var/db/ports/*/options,
>>>>>> basically getting back the pre-OPTIONSng behaviour of being able to
>>>>>> overide port options in /etc/make.conf ?
>>>>>>
>>>>>> Before OPTIONSng was introduced, I was able to specify options in
>>>>>> /etc/make.conf (WITHOUT_X11, WITHOUT_CUPS, WITH_MAILHEAD, WITH_SSL,
>>>>>> WITH_MYSQL, WITH_DOVECOT, ...), which then overode any occurency of that
>>>>>> option in any port (or just specific ones, by e.g. checking .CURDIR),
>>>>>> regardless of the setting the ports option file contained.
>>>>> Find the uniquename of the port[*] (by 'make -V UNIQUENAME') then in
>>>>> /etc/make.conf
>>>>>
>>>>> uniquename_SET= FOO BAR BAZ
>>>>> uniquename_UNSET= BLURFL
>>>>>
>>>>> will override the default settings in that port's Makefile for the FOO,
>>>>> BAR, BAZ and BLURFL options.
>>>>>
>>>>> Note: this won't override any settings you make from an options dialog.
>>>>> Might be a good idea to 'make rmconfig' if you only want to rely on
>>>>> /etc/make.conf
>>>> [...]
>>>>
>>>> Exactly my point.  Currently, with OPTIONSng there seems to be no way to
>>> overide anything in /var/db/ports/*/options.
>>>> I find it irritating, that I no longer can be sure about options in
>>> /etc/make.conf.  I have to check/reconfigure to make sure.
>>>> As much as I like OPTIONSng (especially in combination with
>>> dialog4ports), this is one thing I'd very much like OPTIONSng to relearn:
>>> Enforce options regardless of what's in a ports options file.
>>>
>>> No, that's a bad idea.  It's more confusing to have options not being set
>>> that are checked in the OPTIONS dialog.
>>>
>>> Setting those in make.conf sets defaults, and allows them to be overridden
>>> in individual ports.
>> Let's say I never want CUPS, X11, EXAMPLES and DOCS, regardless of what 
>> I willingly or accidentially configured in an OPTIONS dialog (or is 
>> defaulted to in a ports Makefile), either because I didn't understand 
>> the dependancy of a choice, I fat-fingered something or someone helps me 
>> configuring something, and wants to make sure I get it right:
>>
>> OPTIONS_UNSET_FORCE= CUPS X11 EXAMPLES DOCS
>>
>> Same goes for the complementary case of having options set forcibly, 
>> either system-wide or per port:
>>
>> particularport_SET_FORCE= EXAMPLES DOCS
>>
>> I'd set these in /etc/make.conf, and be done for good.
>>
>> I have a local patch for that kind of behaviour, but wanted to check for 
>> possible alternatives besides the beaten path, before bothering bapt@.
>>
> 
> The thing is half of people wants the /var/db/*/options to be the last word, the
> other half want the behaviour you are exposing, so getting a final word that
> will satisfy everyone is hard.

I think the approach of having a choice between the two by allowing for 
a new 'force it down the throat'-mechanism could serve both quite nicely.

Existing /var/db/*/options files would still be read, but options can be 
forcibly set or unset from /etc/make.conf, overriding the corresponding 
options setting in options files.

> I personnally really dislike /var/db/port/*/options and the dialog :).
>
> The new option framework has been design to:
> 1/ respect the same behaviour has it used to be before: /var/db/port/*/options
> has the final word.
> 
> 2/ provide the ability to users to be able to tune the whole system in a
> consistent way.
> 
> 3/ provide a way to totally disable the dialog thing (NO_DIALOG) so that you
> can't save a option file by mistake.
> 
> What we can probably do in the end is provide a new macro to totally in all
> cases ignore /var/db/port/*/options.
> 
> Would that satisfy your needs?

I'll recap the approaches:

a) Options in /etc/make.conf only take precedence, if no 
/var/db/ports/*/options file exists for a given port

b) Options in /etc/make.conf always take precedence over options of the 
same name read from /var/db/ports/*/options

c) Options in /etc/make.conf are the only source of wisdom, anything in 
/var/db/ports/*/options is ignored


a) is currently in place (*_SET, *_UNSET)
b) is what I'd very much like to see added (*_SET_FORCE, *_UNSET_FORCE)
c) probably comes closer to what you're suggesting

I've attached my current workaround for b), where I simply duplicated 
parts of your code in bsd.options.mk, adding a new suffix.  Maybe this 
further clarifies, what I'm currently missing.

c) would come in handy, if you'd like to make sure nothing whatsoever 
from /var/db/ports/*/options impacts a build.


MfG CoCo


--------------020101010002080200010000
Content-Type: text/plain;
 name="patch.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="patch.txt"

--- Mk/bsd.options.mk.orig	2013-03-17 14:57:27.000000000 +0000
+++ Mk/bsd.options.mk	2013-03-17 17:39:52.000000000 +0000
@@ -199,6 +199,8 @@
 .  include "${OPTIONSFILE}.local"
 .  endif
 
+
+
 ### convert WITH and WITHOUT found in make.conf or reloaded from old optionsfile
 .for opt in ${ALL_OPTIONS}
 .if defined(WITH_${opt})
@@ -225,6 +227,34 @@
 
 .endif
 
+## FORCE
+## Set system-wide defined options (set by user in make.conf)
+.  for opt in ${OPTIONS_SET_FORCE}
+.    if !empty(COMPLETE_OPTIONS_LIST:M${opt})
+PORT_OPTIONS+=  ${opt}
+.    endif
+.  endfor
+PORT_OPTIONS:=  ${PORT_OPTIONS:O:u}
+
+## Remove the options excluded system-wide (set by user in make.conf)
+.  for opt in ${OPTIONS_UNSET_FORCE}
+PORT_OPTIONS:=  ${PORT_OPTIONS:N${opt}}
+.  endfor
+
+## Set the options specified per-port (set by user in make.conf)
+.  for opt in ${${UNIQUENAME}_SET_FORCE}
+.    if !empty(COMPLETE_OPTIONS_LIST:M${opt})
+PORT_OPTIONS+=  ${opt}
+.    endif
+.  endfor
+PORT_OPTIONS:=  ${PORT_OPTIONS:O:u}
+
+## Unset the options excluded per-port (set by user in make.conf)
+.  for opt in ${${UNIQUENAME}_UNSET_FORCE}
+PORT_OPTIONS:=  ${PORT_OPTIONS:N${opt}}
+.  endfor
+
+
 ## Cmdline always win over the rest
 .for opt in ${WITH}
 .  if !empty(COMPLETE_OPTIONS_LIST:M${opt})

--------------020101010002080200010000--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1363549575.86830.YahooMailNeo>