From owner-freebsd-ports@FreeBSD.ORG Tue Dec 9 22:21:07 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 5B69D1065670 for ; Tue, 9 Dec 2008 22:21:07 +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 CED428FC1A for ; Tue, 9 Dec 2008 22:21:06 +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 1LAAwx-0003vJ-MQ; Wed, 10 Dec 2008 01:21:03 +0300 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id B688DA017; Wed, 10 Dec 2008 01:19:48 +0300 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id 722581702D; Wed, 10 Dec 2008 01:20:42 +0300 (MSK) Date: Wed, 10 Dec 2008 01:20:42 +0300 From: Dmitry Marakasov To: Ashish Shukla =?utf-8?B?4KSG4KS24KWA4KS3IOCktuClgeCkleCljeCksg==?= Message-ID: <20081209222042.GC29817@hades.panopticon> References: <87fxkxjywk.fsf@chateau.d.lf> <20081209143052.GA29817@hades.panopticon> <873agxjn1x.fsf@chateau.d.lf> <20081209181354.GB29817@hades.panopticon> <87tz9di38u.fsf@chateau.d.lf> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87tz9di38u.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 22:21:07 -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: > > No, those problems will not arise as long as the maintainer tests the > > port before submitting an update. And the tested port of fixed versio= n > > will be usable for a long time, unlike SCM-based one which may break > > every second. >=20 > That is true, but the only problem I see with snapshots is, if > maintainer is busy you can't do anything There's no other way, unfortunately. There's 2 weeks maintainer timeout (usually pot gets committed somewhere between 2 weeks and 1 month). But there was and idea of having multiple maintainers for a port, maybe it could lower response times. > except maintaining your own local port version on your box. And > anyone using these SCM ports is the one who knows things can go > wrong often, and this is only for development use. Having bleeding edge software and support for development versions is not the goal of ports (though I consider ports pretty good in those). Ports are intended for everyone's use and are expected to be more or less stable. > > 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 al= l. > > I'm currently doing some experiments. >=20 > Cool, would like to see the results of your experiments :). I will post something on this list if I manage to get any useful results. > > 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 > Gentoo GNU/Linux which is a source-based GNU/Linux distribution has thi= s > feature available, what is different in that is, that it uses a separat= e > root for recording the packing list port and optionally creating a > package. Yes, I've heard of it. Maybe I'll look closely at how it's done. > Maybe we can introduce a hack in ports system like by adding some > variable like 'USES_DYNAMIC_PLIST=3Dyes' in Makefile, which fill let th= e > port first installed with DESTDIR=3D/var/tmp/ports/${PORTNAME} and then= a > packing list is generated and then finally whole tree is moved to > ${PREFIX}, hmm...? What do you say ? Current DESTDIR implementation uses chroot and obviously requires complete system installed in DESTDIR. Also installing a port will install all dependencies in the chroot as well. There was proposal of another implementation that would behave as you describe without chroot, but it would require too much work, as most ports will need hacks so they install software into ${DESTDIR}/${PREFIX}, but the software would think that it's installed into ${PREFIX}. That is not even always possible, so the idea was dropped. Thus, the only reliable way to generate plist with standart tools is using fat chroot. My idea however is monitor all filesystem writes by port's make and all descendant processes. That may be done with monitoring or replacing syscalls and may be done with LD_PRELOAD or some *trace kernel facilities. The former is what I'm currently experimenting with. > P.S. do you've any ideas about when a discussion on this subject took > place on this list, hmm..? The last one was, afair, this one: http://groups.google.com/group/mailing.freebsd.ports/browse_thread/thread= /5f6fca39526c0fc4/8987f328fd95f0c5?lnk=3Dgst&q=3Dfetch+from+vcs#8987f328f= d95f0c5 there should be more http://groups.google.com/group/mailing.freebsd.ports/search?group=3Dmaili= ng.freebsd.ports&q=3Dfetch+from+repository --=20 Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru