From owner-freebsd-ports@FreeBSD.ORG Sat Jun 19 11:55:26 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 041AD16A4CF for ; Sat, 19 Jun 2004 11:55:26 +0000 (GMT) Received: from fillmore.dyndns.org (port-212-202-50-15.dynamic.qsc.de [212.202.50.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C48A43D4C for ; Sat, 19 Jun 2004 11:55:25 +0000 (GMT) (envelope-from eikemeier@fillmore-labs.com) Received: from [172.16.0.13] (helo=localhost) by fillmore.dyndns.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34 (FreeBSD)) id 1BbeQy-000LxP-L8; Sat, 19 Jun 2004 13:54:58 +0200 Date: Sat, 19 Jun 2004 13:54:59 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) To: Thomas-Martin Seck From: Oliver Eikemeier In-Reply-To: <20040619104053.GA568@laurel.tmseck.homedns.org> Message-Id: <7D423A4F-C1E7-11D8-9250-00039312D914@fillmore-labs.com> Content-Transfer-Encoding: 7bit User-Agent: KMail/1.5.9 cc: freebsd-ports@freebsd.org Subject: Re: CONFLICTS usage question X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2004 11:55:26 -0000 Thomas-Martin Seck wrote: >> The point I'm making here is that you are deliberately breaking some >> basic mechanisms of the ports system, not caring about the >> consequences, >> because it works for you. Have you ever tried to add new features to >> the >> ports system, only to see that 1% of the ports are failing because they >> use creative solutions or are just too lazy to adhere to the standards? > > Oliver, I say this once and for all: > > Please do not claim that "I am deliberately breaking something". This is > not correct and I take offence by this. I tried my best to remove > self-conflictness in the squid ports I maintain, so please take a deep > breath before you talk on, will you? I'm sorry if you feel offended, this was not my intention. I apologize for the harsh tone, but how should I understand > [port (deliberately) CONFLICTS with itself] then? > Give me a sound reason why things are as they are and I am silent, trust > me. On the other hand, "explanations" of the kind "I say so and so be > it, infidel" make me ask questions. Sorry, but I did not get any > technical answer beyond "it's bad, you break things, because I say so". The problem here is what individual maintainers consider to be `a sound reason'. I had various discussions about PKGORIGIN, why port versions shouldn't go backwards, why port versions shouldn't mutate depending on configuration options, why you shouldn't change your port name depending on configuration options, the list goes on. Sometimes maintainers are not very cooperative when you tell them you need stuff a certain way, and demand increasingly complex examples why this will break certain constructs. This may be personal freedom, but makes live very hard when you try to write tools that work on the whole ports tree, only to find out that _some_ ports decide to do things differently. Back to start, explain, provide examples... It may be very democratic this way, and may be educational, but it is lost development time. I would love it when sometimes port maintainer would just fix their port names and conflicts like *I* need them (yes, I'm egoistic) and instead use their creativity to provide patches for the tools I write, or come up with their own. The world isn't that way in the land of strong code ownership, I know. > [etc/leapseconds] > >>>> Which ports are you referring to? >>> >>> devel/libtai and mail/mess822. >> >> That should be easily fixable, please send-pr a patch. > > If you move away leapsecs.dat from ${PREFIX}/etc, you will probably > break applications which use libtai. This is not so trivial, I guess. > See below. With `fixable' I meant just adding CONFLICTS to both ports. > This is btw just an examble of the subleties of proper conflicts > checking. Yep. I wonder what will break when I do automatic CONFLICTS checking. >>> sysutils/clockspeed installs leapsecs.dat >>> to etc/clockspeed; I do not know whether this makes sense at all (i.e. >>> whether sntpclock would look there for it; I did not look at the code >>> though). >> >> Does this conflict with anything? Considering the name of the >> directory I >> wouldn't assume this. > > It doesn't conflict, but it does not make sense either. According to > libtai's leapsecs(3), leapsecs.dat *must* be installed to ${PREFIX}/etc/ > to take any effect. So its up to the maintainers to coordinate with each > other (or, come to think of they need to check whether the file is > already present and install it as file.portname). Seems like you highjacked the thread to discuss something off-topic here. -Oliver