From owner-freebsd-ports@FreeBSD.ORG Sat Jun 19 13:43:23 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 57CE316A4CE for ; Sat, 19 Jun 2004 13:43:23 +0000 (GMT) Received: from smtp2.netcologne.de (smtp2.netcologne.de [194.8.194.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id C92BF43D54 for ; Sat, 19 Jun 2004 13:43:22 +0000 (GMT) (envelope-from tmseck-lists@netcologne.de) Received: from laurel.tmseck.homedns.org (xdsl-81-173-176-230.netcologne.de [81.173.176.230]) by smtp2.netcologne.de (Postfix) with SMTP id 3B4684856 for ; Sat, 19 Jun 2004 15:43:20 +0200 (MEST) Received: (qmail 13666 invoked by uid 1001); 19 Jun 2004 13:43:36 -0000 Date: Sat, 19 Jun 2004 15:43:14 +0200 From: Thomas-Martin Seck To: Oliver Eikemeier Message-ID: <20040619134314.GE568@laurel.tmseck.homedns.org> References: <20040619104053.GA568@laurel.tmseck.homedns.org> <7D423A4F-C1E7-11D8-9250-00039312D914@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7D423A4F-C1E7-11D8-9250-00039312D914@fillmore-labs.com> User-Agent: Mutt/1.4.2.1i Organization: a private site in Germany X-PGP-KeyID: DF46EE05 X-PGP-Fingerprint: A38F AE66 6B11 6EB9 5D1A B67D 2444 2FE1 DF46 EE05 X-Attribution: tms cc: freebsd-ports@freebsd.org Subject: CONFLICTS handling (was: 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 13:43:23 -0000 * Oliver Eikemeier (eikemeier@fillmore-labs.com): > Thomas-Martin Seck wrote: > >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? As a feeble attempt to summarize the discussion so far. I thought about what I did when I created the conflicts pattern for www/squid{,24}. I just wrote squid-* and accepted that the port would in the end conflict with itself and considered this to be OK. This is of course a deliberate self-conflict. But see my other posts in the original thread about why I think that bsd.port.mk should not be overly picky about it. > >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. I understand that you investigate a lot of time and effort but please remember: most maintainers don't. Sometimes it is just not easy to understand why some things are "bad". If a maintainer is expected to implement things in a certain way, document it extensively and provide cut-and-pasteable templates and have portlint(1) check it. To me it seems that you take scepticism as a personal offence. Please relax, document what you want people to do and communicate it. This will convince at least me quicker than you might think. And do not give others the impression that you are right or "more right" than them (even if you are). > >[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. It's not that easy, see below. > >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. A lot of things will. You need to have a clear concept how to deal with it, see below. > >>>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. Maybe. I'm just asking you: what is your or portmgr's plan regarding conflicts outside of bin, sbin, and libexec and non-trivial conflicts in general? Keep in mind that we have two classes of conflicts to deal with: Most conflicts regard binaries and are often obvious: users usually have no need to, say, run squid-2.4 and squid-2.5 in parallel so checking for a conflict and prohibiting the install is OK. Things get different when completely unrelated packages install binaries with the same name. I do not have an example but there seems to have been at least one case, see under "Name conflicts" where wuftpd and hylafax used to install a sbin/xferstats utility. How am I as a maintainer supposed to handle that? How shall I go about other conflicts, e.g. etc/leapsecs.dat? Is there one port who is allowed to install it to etc/, the other ports must install it to etc/${PORTNAME}/leapsecs.dat? Or should they install it to etc/leapsecs.dat.${PORTNAME}? The same applies to binaries, if we stick to the example above, both wuftpd and hylafax have a valid reason to install a xferstats utility to sbin. Mutt and Tin have a valid reason to install an mbox(5) manpage and so on. There needs to be a tool to check for conflicts and a clear strategy how to resolve a non-trivial conflict before the port gets committed. You cannot run around, stick CONFLICTS to ports and be done with it. If you do not make it clear how things are to be done, maintainers will do whatever they think is best. And the ports tree will be as inconsistent as it is now. So, the only thing I ask for is: if you or portmgr comes up with a solution, do not feverishly "correct" other peoples ports but hand out clear guidelines what to do and give me a change to do it right myself.