From owner-freebsd-ports@FreeBSD.ORG Tue Dec 9 18:14:18 2008 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E3C31065680 for ; Tue, 9 Dec 2008 18:14:18 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [217.170.79.85]) by mx1.freebsd.org (Postfix) with ESMTP id 1FB558FC13 for ; Tue, 9 Dec 2008 18:14:17 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LA76A-0008GA-QJ; Tue, 09 Dec 2008 21:14:18 +0300 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id E3A2E5DA3; Tue, 9 Dec 2008 21:12:59 +0300 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id 20D101702D; Tue, 9 Dec 2008 21:13:54 +0300 (MSK) Date: Tue, 9 Dec 2008 21:13:54 +0300 From: Dmitry Marakasov To: Ashish Shukla =?utf-8?B?4KSG4KS24KWA4KS3IOCktuClgeCkleCljeCksg==?= Message-ID: <20081209181354.GB29817@hades.panopticon> References: <87fxkxjywk.fsf@chateau.d.lf> <20081209143052.GA29817@hades.panopticon> <873agxjn1x.fsf@chateau.d.lf> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <873agxjn1x.fsf@chateau.d.lf> User-Agent: Mutt/1.5.18 (2008-05-17) Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Ports Mailing List Subject: Re: [PROPOSAL] Ports using SCM repositories as source instead of distfiles 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: Tue, 09 Dec 2008 18:14:18 -0000 * Ashish Shukla =E0=A4=86=E0=A4=B6=E0=A5=80=E0=A4=B7 =E0=A4=B6=E0=A5=81=E0= =A4=95=E0=A5=8D=E0=A4=B2 (wahjava.ml@gmail.com) wrote: > > - _Much_ more (instead of less) work for maintainer, as he won't be a= ble > > to test the port before committing it and will have to deal with al= l > > the problems post factum, under extra pressure. >=20 > > - Actually, any SCM-based port will become broken rather soon than > > later with no ability to prevent it. > > The port uses patches? Due to mutable source it'll become broken. > > Any structural change upstream? Port broken. Changed build system? > > Broken. Changed paths? Broken. Changed depends? Broken. Changed > > options/configure args? Broken. Etc. >=20 > These are the problems already expected with this but the only > suggestion is to have PRs filed if anything breaks during compilation > and investigate what caused it. No, those problems will not arise as long as the maintainer tests the port before submitting an update. And the tested port of fixed version will be usable for a long time, unlike SCM-based one which may break every second. > > - Generic dynamic plist generation is impossible unless the port > > is installed into some clean chrooted environemnt (for example, > > using DESTDIR). The latter, however takes extra space and time, > > as you need the whole system and all dependent packages installed > > there as well. >=20 > So, this is the main reason which prevents this :( . I'd say it's the least significant reason. The main reasons are the first three which can be shortened as `the port will be unuseable and sometimes dangerous'. What's for automatic plist generation, I've given it some thought, and it seems like there could be a more or less reliable way after all. I'm currently doing some experiments. > > Sometimes it's hard to tell whether the problem is FreeBSD-specific. > > Also, upstream is unlikely to have FreeBSD box for testing, so again > > it'll be more work for maintainer. >=20 > True, so either have all PRs should be submitted to FreeBSD PR system, > where maintainer will decide if its porting issue or upstream related > issue. My opinion is that if you can diagnose the problem by yourself and come with a proper fix, you should submit it directly upstream. If you think that the problem is serious enough, you can send a port PR as well. If you cannot do it all by yourself though, you should submit a PR, in which case port's maintainer will take care of it. > So with all the problems you mentioned above, I guess, I'll take my > proposal back :) . It's not like your proposal is bad, ports instantaneously tracking upstream changes and not needing maintainers would really be cool, but unfortunately that's practically impossible. --=20 Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru