From owner-freebsd-ports@FreeBSD.ORG Wed Apr 30 10:55:59 2008 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9879D1065672; Wed, 30 Apr 2008 10:55:59 +0000 (UTC) (envelope-from david@wood2.org.uk) Received: from v-smtp-auth-relay-1.gradwell.net (v-smtp-auth-relay-1.gradwell.net [79.135.125.40]) by mx1.freebsd.org (Postfix) with ESMTP id 8156B8FC1D; Wed, 30 Apr 2008 10:55:58 +0000 (UTC) (envelope-from david@wood2.org.uk) Received: from argon.wood2.org.uk ([82.71.104.124] country=GB ident=postmaster&pop3#wood2$org&uk) by v-smtp-auth-relay-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4818503c.7600.1c1; Wed, 30 Apr 2008 11:55:56 +0100 (envelope-sender ) Message-ID: Date: Wed, 30 Apr 2008 11:54:23 +0100 To: "Aryeh M. Friedman" From: David Wood References: <20080429184420.GB5010@dose.local.invalid> <48178247.2010008@gmail.com> <20080429212721.GA5795@dose.local.invalid> <4817D91E.1040900@gmail.com> <48181A2A.1000303@gmail.com> In-Reply-To: <48181A2A.1000303@gmail.com> MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed User-Agent: Turnpike/6.06-M (<+nhRuLNS5oZIqwOH7WWZxwfp$O>) Cc: Jim Stapleton , Alexander Ryba , ports@FreeBSD.org, Jacobus Geluk , Simon Barner , Jeremy Messenger Subject: Re: Is someone already working on a port that supports Boost 1.35.0? X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2008 10:55:59 -0000 [Additional CCs added by Aryeh noted, but left untouched] I wanted to retitle this post, but couldn't come up with a summary of what I was trying to say. In message <48181A2A.1000303@gmail.com>, Aryeh M. Friedman writes >I am top posting because my comments are general and not in >relationship to any given point. I think Mezz along with Simon both >the right way to handle it for now. There are several projects that I >am not directly involved designed to tackle this sort of issue with >ports 2.0 being the right long term solution but not needed to solve >this issue per se so I will not discuss it here. Most of the projects >can be found on Ale's PortsToDo wiki (wiki.freebsd.org/PortsToDo) the >main one not found on there is Jim Staplton's virtual ports DB (which I >think is either in the committ queue or should be since both me an Ale >have signed off on it as being a good idea). The issue is really not >the infrastruct as you state but the more patchs like this we make the >more likely it is the infrastruct will become problematic down the road. Forgive me, Aryeh, but you've taken a specific point I made and dismissed it saying that "the infrastructure needs a complete overhaul and I'm the right person to head that work", though you have acknowledged that there is other work going on. I know you will argue you aren't making a reply to my post, so why didn't you trim all my text instead of quoting it? I believe you are replying - and that your reply is pretty close to being non sequitur. I am not interested in pointless points scoring; I have better things to do. What I want to do is understand the issue.. I am no committer - just a mere ports maintainer. Freshports doesn't dig up any ports you maintain, at least not with an email address beginning with aryeh or containing fried. http://tinyurl.com/585dtk shows my interest. net/freeradius is a fairly complicated port, (optionally) depending on MySQL, PostgreSQL, OpenLDAP, Kerberos and python (the python dependency is controlled by the EXPERIMENTAL option). There's also a dependency on OpenSSL - either the base version, or, if it's available, ports OpenSSL. The SQL dependencies are pretty straightforward, so long as you remember that you can only have one version of each of the clients on a particular machine. OpenLDAP is a little tricky, in that there's not only different versions in ports, but also the ability to build the OpenLDAP client with and without SASL. However, most administrators set the appropriate knobs via portconf or similar; it's usually appropriate to depend on whatever is on the system already, or build whatever the default is after any administrator applied overrides and depend on that. There's LDAP handling in bsd.port.mk, which helps the maintainer. Kerberos is trickier still, in that you can only have one flavour of Kerberos on a system, and there's no USE_KERBEROS mechanism. Instead, a port needs to allow the choice of one of {nothing, Heimdal, MIT Kerberos} - which can't be done with yes/no questions without having two interdependent questions. Some ports have one option to depend on MIT Kerberos and another to depend on Heimdal, terminating with an error if both are set. Other ports, like FreeRADIUS, have one option to depend on Kerberos, and another to choose Heimdal or MIT Kerberos. This is another situation where bsd.options.mk might help - it might be possible to test if one or other flavour of Kerberos has been installed from ports and set the default appropriately, though a lot of features are unavailable before bsd.port.pre.mk has been included. python is the real problem amongst those dependencies - but it won't be for much longer. As soon as possible after 31 May, I will be sending in a PR to remove the current python hack in net/freeradius and use bsd.options.mk instead. I do not believe that this problem is one that brings into question the whole infrastructure. It certainly isn't "the more patchs (sic) that we make the more likely it is that the infrastruct (sic) will become problematic down the road". Not all evolutionary software engineering is bad, especially if modules are rewritten when appropriate. Of course I accept the possibility of 'bit rot' setting in when code has been through many hands and has many small changes applied. In this case, I believe that things are getting better, not worse or less maintainable. This problem was known about some while back and there's no need to do any fresh engineering. The delay in having a solution available was the need for changes in the base system to support bsd.options.mk. Base system changes mean waiting until all versions of FreeBSD that lack the necessary support are End of Life. After 31 May, ports will be able to process their options and set a dependency on python before including bsd.pre.port.mk. A simple and elegant solution will soon be available to solve what is essentially a circular dependency at the moment. I see two issues here, both stemming from the complexities of dependency between ports. Firstly, there's a need to look for the best possible solutions with the tools we have now as well as to look for continuing improvement. Secondly, there's the need to educate both maintainers and administrators on how best to handle the complexities that can occur. I think everyone would agree that the current documentation isn't the best. In stating this, I believe I'm restating Mark Linimon's well known criticism of the current Porters' Handbook. It is not my intention to hurt anyone by what I say. The way out of this is, of course, for people to pay attention to the documentation - but those best placed to do that are some of the busiest people already within the FreeBSD project. Having worked alongside technical authors, I realise what a specialist (and impressive) skill set they have. At the moment, it is hard for a maintainer to discover current best practice. I suspect this is partly why the same issue is handled in different ways by different ports (as I mentioned above with Kerberos). Meanwhile, it is hard for system administrators to discover how best to use the richness of ports. System administrators need the freedom to make whatever decisions they feel are appropriate (as I said, I wouldn't want ports unnecessarily depending on OpenSSL or the Cyrus SASL library). However, features that help administrators manage this richness, such as portconf, are not that well known about, especially by the less technical users. Aryeh - you seem to have something against slave ports. At times, they are very useful. They make the creation and maintenance of client/server ports easy - for example, databases/mysql50-client is a slave port of databases/mysql50-server. net/freeradius-mysql was created as a slave port of net/freeradius for work being done with pfSense. The need was for a FreeRADIUS package with MySQL support built in. The easiest way to ensure the necessary package is available from the FreeBSD servers is with a slave port. There are times when a slave port that enables one option makes sense. However, slave ports that enable a single option in their master port can be troublesome. The example that comes to mind here is devel/subversion and the slave ports devel/subversion-perl, devel/subversion-python and devel/subversion-ruby. All these slave ports do is enable the appropriate language binding in Subversion. The options they enable aren't mutually exclusive, but these ports all conflict with each other, which can lead to problems. The language bindings aren't the defaults because of the dependency on a sizeable language port that isn't installed by default (there's also a fourth optional binding, which is Java). The Subversion slave ports illustrate the problems caused by not necessarily being able to determine the options used for a particular port or package. edwin@ has already covered this at http://wiki.freebsd.org/RewriteOfOptions by noting the wish for ports to be able to depend on (or at least test) OPTIONS of other ports. Another wish expressed there is a way of representing That, by itself, doesn't need a new ports infrastructure - though it does need carefully thinking through in both the port and package cases. Options 2.0 is certainly being thought about - and whilst it touches on dependency graphing and other things you've mentioned in connection with your proposed "Ports 2.0", Aryeh, it doesn't necessarily need to change the way dependencies are currently handled - just enhance them. The reason for both my posts is a feeling that you haven't understood *why* the current situation is as it is, Aryeh. A reply along the lines of "we're working on a complete replacement of the whole infrastructure, and that will solve it" doesn't help with understanding the specific issue that has arisen. You can't offer any guarantee that your new system will solve all the problems - especially if you do not take the time to understand the weaknesses in the current system as well as its strengths. If you bring forward coherent proposals and a proof of concept for Ports 2.0, I will certainly give what input I can at that stage. For now, we live with and continue to improve what we have, rather than looking only to what might replace it if it's found to be better after careful evaluation. Maintainers have to work with OPTIONS as they are. They are a valuable feature, even if they don't offer all the functionality wished for. Best wishes, David -- David Wood david@wood2.org.uk