From owner-freebsd-ports@FreeBSD.ORG Fri Aug 20 08:50:20 2010 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 9514910656A6; Fri, 20 Aug 2010 08:50:20 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id F2C3D8FC17; Fri, 20 Aug 2010 08:50:19 +0000 (UTC) Received: by wyj26 with SMTP id 26so3888105wyj.13 for ; Fri, 20 Aug 2010 01:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:message-id:mime-version:content-type:content-disposition :user-agent; bh=a1Yuo4KyihTSxa/LTMf107s5I35wIBWaYevb3fpC65c=; b=l1jPVFkAvig6xcvXpBP0Lvs0igX0iSf2tVyp4Xo8bkxBUBX/YEjRBFtyOVFB2ZlXpu 5sRTuIgFEuDcZv7IqArCJ86VZWh6T0dmyePjxL5YlM9O4QHQcTiLY0OnPure6VFkWRku frdbC+Vox4o21qRSSsmv4grJRBOLViAfSUw7s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:user-agent; b=SEVfh6Df4+CtRr7lad61BDFPMyddWWVdABE9Vr6stAyZx+1TN8MwP6gsICsNcGZguz +wC7QWANEs4zQKZ/K1W3HMeZSRx34lBDNgFQACQNv5MsjBx23QEa/zdAF3SIfj8lzCou G/KJ58L4lFcYS9ZOUazTy2DYlKDmRvakAJ9cY= Received: by 10.216.10.77 with SMTP id 55mr897570weu.17.1282294218265; Fri, 20 Aug 2010 01:50:18 -0700 (PDT) Received: from azathoth.lan (stc92-3-82-245-249-89.fbx.proxad.net [82.245.249.89]) by mx.google.com with ESMTPS id k7sm1616960wej.26.2010.08.20.01.50.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Aug 2010 01:50:17 -0700 (PDT) Sender: Baptiste Daroussin Date: Fri, 20 Aug 2010 10:50:29 +0200 From: Bapt To: jhell Message-ID: <20100820085029.GA1786@azathoth.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Florent Thoumie , Julien Laffaye , David Forsythe , Garrett Cooper , Tim Kientzle , Ivan Voras , freebsd-ports@freebsd.org, Garrett Cooper Subject: Re: what next for the pkg_install rewrite 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: Fri, 20 Aug 2010 08:50:20 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I agree having a packaging@ mailing list would help to discuss about pkg_install stuff. We need to summarize the ideas of each one, then discuss about it. Only then we can specified what needs to be done and how (keeping in mind that we need to keep compatibility at least as a fallback or directly). when that part of the work is done we could be able to propose the statement to portmgr for them to validate and to update the ports policy if needed (hopefully they would have taken part in the discussion so the validation should be formal) If everyone agree with the following: What I propose to do is to let the discussion going on for the next couple of days (or moredepending on the activity on this thread) and then write down all that has been proposed (pro, con) then we should be able to start the specification for pkg_install next generation :) I propose myself as someone has to do the job, but if you think you or other are better suited for the job go ahead propose yourself or name the one you want to punish. back to the subject. I personnaly believe that pkg_install needs a complete rewrite. we have strong basis, libarchive, the GSoC code: libpkg, pkg_complete and many more (pkg_patch) (sorry if I forgot some). The new specifications has to be validated by portmgr at the begining of the project and the code should repect that specifications: once we have all accepted what would become the new pkg_install we won't add features or behaviour that are not in the specification until the release and integration in base. We need to centralized the code in the same place with the same scm (I would love if we could avoid p4 :)) ideas are welcomed :) We need to keep the compatiblity (as much as possible) with the existing pkg_install, through wrappers, scripts, or fallback code. The Plist has to be reworked: a new clean format which represents the new features that ports provide I also agree that pkgname and version should be separated A new policy on package names should be written to prevent the apr case or at least internally the package origin should be used to identify the packages. perhaps we could keep the informations on the build options within the metadatas Package should know which architecture they are made for : i386, amd64, noarch, etc. It would allow to prevent rebuilding of cross plateform package on clusters, it would allow to prevent being able to install sparc64 package on i386? regards, Bapt --jI8keyz6grp/JLjh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAkxuQdUACgkQ8kTtMUmk6EzDfACeO0kPmKf/r0GF22NOzScjZLNJ cbMAn1fs+uA1PrPx4tZnhR/mxNEYp3yJ =N4rY -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh--