From owner-freebsd-ports@FreeBSD.ORG Mon Dec 17 16:00:07 2007 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 4B9D416A417 for ; Mon, 17 Dec 2007 16:00:07 +0000 (UTC) (envelope-from alepulver@FreeBSD.org) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.freebsd.org (Postfix) with SMTP id 096E313C45D for ; Mon, 17 Dec 2007 16:00:06 +0000 (UTC) (envelope-from alepulver@FreeBSD.org) Received: (qmail 8569 invoked by uid 0); 17 Dec 2007 16:00:05 -0000 Received: from unknown (HELO deimos.mars.bsd) (unknown) by unknown with SMTP; 17 Dec 2007 16:00:05 -0000 X-pair-Authenticated: 200.127.63.61 Date: Mon, 17 Dec 2007 12:59:54 -0300 From: Alejandro Pulver To: Brian Message-ID: <20071217125954.22b3bff4@deimos.mars.bsd> In-Reply-To: <47668B49.7050804@brianwhalen.net> References: <4766650C.4020305@gmail.com> <47668B49.7050804@brianwhalen.net> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.1; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/dXQJNGf.q1gr.KgA_MP8TKB"; protocol="application/pgp-signature"; micalg=PGP-SHA1 Cc: "Aryeh M. Friedman" , freebsd-ports@freebsd.org Subject: Re: Request for Features: Ports Re-engineering 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: Mon, 17 Dec 2007 16:00:07 -0000 --Sig_/dXQJNGf.q1gr.KgA_MP8TKB Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 17 Dec 2007 06:44:25 -0800 Brian wrote: > Aryeh M. Friedman wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > In order to finalize the general nature of the ports re-engineering > > effort this thread is designed to specifically explore the features > > people want to see. > > > > Please supply one or more of the following: > > > > * Up to 4 user stories of how you would like to use the ports system > > (may or may not be possible in the current one) > > * Up to 4 use cases for how you would like to interact with the ports > > system > > * Up to 4 features/requirements you think the new system should have > > * Up to 4 features/requirements that you feel *MUST* remain from the > > current system > > * Any non-functional requirements you can think of > > [...] > I dont use X on FreeBSD, so cannot comment on al th Xorg stuff. Keeping= =20 > in mind that I believe it is appropriate for this new tool to make it at= =20 > lest a little easier on new users, while still giving them valuable=20 > info, I suggest the following. >=20 > 1. I would like for the new equivalent of portupgrade -P to actually=20 > find and install packages more often than building ports, currently this= =20 > is not the case, for me at least. IIRC this issue isn't related to portupgrade but to the package builds, which aren't always up-to-date with ports. And this has to do with available resources to build them. Of course if the ports system performance is optimized they will build faster. But in general I think improvements could be made, like (if not already done, AFAIK tinderbox has an option to run parallel builds, but don't know about pointyhat) using multiple processors. And maybe even a new build system that doesn't completely recreate the clean environment every time. > 2. If the tool implemented the functionality of fastest_cvsup when=20 > downloading files from FreeBSD servers, users would likely see a=20 > performance improvement, and FreeBSD would likely see better load=20 > distribution. Ordering preference of MASTER_SITES would be a good feature, combined with speed calculation. Currently there is only RANDOMIZE_MASTER_SITES. The new system will be modular from the beginning so adding more and more things shouldn't result in performance overhead (as it happens now). > 3. System changes that are necessary for proper functionality are=20 > delivered via email to a specified email address or to some easy to find= =20 > and refer to file, with the option to have them done by the install=20 > routine if the user desires that. This is currently up to the maintainer, and some framework should be provided by the system. > 4. Log of what ports were installed/upgraded/downgraded at what time. >=20 portupgrade already has logging facilities (I guess you already know), but integrating them in the system would offer some advantages: 1. Ability to avoid showing build output, keeping it in the log. 2. Keeping track of port operations internally (which could be useful for processing files like UPDATING/MOVED later, and security checks). 3. Accurate automated bug-report generation. Best Regards, Ale --Sig_/dXQJNGf.q1gr.KgA_MP8TKB Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHZpz6iV05EpRcP2ERAoL6AKCNFLSQ4jLFA723tySPR690sE7bIwCgwF8x wT0TXyufc6l13PPQv700rFE= =zCRi -----END PGP SIGNATURE----- --Sig_/dXQJNGf.q1gr.KgA_MP8TKB--