From owner-freebsd-ports@FreeBSD.ORG Sun May 13 11:53:55 2007 Return-Path: X-Original-To: freebsd-ports@FreeBSD.org Delivered-To: freebsd-ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E502116A400 for ; Sun, 13 May 2007 11:53:55 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 352C713C4BB for ; Sun, 13 May 2007 11:53:54 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 13 May 2007 11:53:53 -0000 Received: from nat-wh-1.rz.uni-karlsruhe.de (EHLO mobileKamikaze.norad) [129.13.72.169] by mail.gmx.net (mp028) with SMTP; 13 May 2007 13:53:53 +0200 X-Authenticated: #5465401 X-Provags-ID: V01U2FsdGVkX18NEABMJAkNLNcWzoxNd2/lxsVGNV/usj62TpqFPj Ubq22+YaFrmWWT Message-ID: <4646FC39.7080501@gmx.de> Date: Sun, 13 May 2007 13:53:29 +0200 From: "[LoN]Kamikaze" User-Agent: Thunderbird 2.0.0.0 (X11/20070506) MIME-Version: 1.0 To: Lev Serebryakov References: <464597C6.3030406@gmx.de> <20070512174011.GA22526@xor.obsecurity.org> <1996124170.20070513151450@serebryakov.spb.ru> In-Reply-To: <1996124170.20070513151450@serebryakov.spb.ru> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-ports@FreeBSD.org, Kris Kennaway Subject: Re: Time to abandon recursive pulling of dependencies? 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: Sun, 13 May 2007 11:53:56 -0000 Lev Serebryakov wrote: > Hello Kris, > > Saturday, May 12, 2007, 9:40:11 PM, you wrote: > > KK> I think that before you abandon something you should first understand > KK> it. > Can you explain, why we need to register "A depends on C / C required by A" in A -> B -> C chain? > I can not see any advantages, only disadvantages: > > (1) Long registration time in case of big dependency trees > (2) There is no way to say quick, why port X is installed: it can have zillion other ports in +REQUIRY_BY, but, really, be only optional dependency of one of these ports Y (and don't needed by others, but others really need Y). > (3) If port A has optional dependincy B and C depends on A, we need to fix C registartion when A is rebuilt without B... > > I'm not smarter than ports subsystem authros and maintainers. It means, that I overlook some HUGE advantage to have flatten dependency tree in every port/package registartion. > What do I overlook? I tried it and the change would probably require a massive overhaul of the ports infrastructure. Apart from that, I still think not pulling in dependencies would be better, but the decision has been made long ago and now can hardly be reversed. Maybe something in the scale of a summer of code project could address this, but external tools like portupgrade would have to be changed as well.