From owner-freebsd-ports@FreeBSD.ORG Mon May 24 11:38:50 2004 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A5D416A4CE for ; Mon, 24 May 2004 11:38:50 -0700 (PDT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id A108B43D1F for ; Mon, 24 May 2004 11:38:49 -0700 (PDT) (envelope-from apeiron@comcast.net) Received: from prophecy.velum (pcp08490587pcs.levtwn01.pa.comcast.net[68.83.169.224]) by comcast.net (sccrmhc11) with SMTP id <2004052418380601100leamle> (Authid: apeiron@comcast.net); Mon, 24 May 2004 18:38:06 +0000 Date: Mon, 24 May 2004 14:38:04 -0400 From: Christopher Nehren To: Garance A Drosihn Message-ID: <20040524183804.GA53827@prophecy.dyndns.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: freebsd-ports@freebsd.org Subject: Re: Third "RFC" on on pkg-data ideas for ports X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2004 18:38:50 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 24, 2004 at 00:07:34 EDT, Garance A Drosihn scribbled these curious markings: > The third proposal is basically: > a) move most "standard" files into a new pkg-data > file, as described in previous proposals, except > for pkg-descr and "patch" files. Yuck. I don't want to have to navigate a large file just to see how to enable something or change something for a port, or check its plist, etc. And, how do you suppose 'make' will work? Are you suggesting hard-coding it to read pkg-data files? That's extremely kludgish. Alternatively, are you supposing a totally new command structure to build ports? If so, I=20 commend you for your audacity and bravery. Good luck getting your idea=20 accepted, and keep in mind that you'll be breaking many, many scripts=20 and programs (portupgrade not the least of which...). > b) create a new directory at the root directory of > the ports collection. That directory would be > called "Patches", and inside would be a directory > for each category. Inside each Patches/category > directory would be a single-file for each port > in that category, where that single-file would > have all the "ports-collection patches" for the > matching port. What's wrong with files/ ? Remember, there are things in files/ that aren't always just patches. Take a look at net/dictd/files for example. If you plan to keep files/ for non-patch files, I don't like that idea either. I don't want to have to use three '../'s to switch between=20 viewing non-patch files and viewing patch files. See below about "more typing". > c) [minor] in the pkg-data section for distinfo, I'd > like to change the format for each file from, eg: > MD5 (bash-2.05b.tar.gz) =3D 5238251b4926d778dfe162f6ce729733 > SIZE (bash-2.05b.tar.gz) =3D 1956216 > to > 5238251b4926d778dfe162f6ce729733 1956216 bash-2.05b.tar.gz I don't have a problem with this, as it increases the scriptability factor. Though I'd prefer to see that replace distinfo, rather than go into your panacea file. > result in as dramatic a drop in inodes, but it has the nice > side-effect that Patches are separated from all the other files. In all honesty, why would you want to do that? It's just more typing. And from the perspective of a Perl programmer, that's a Cardinal Sin,=20 as it breaks the Holy Virtue of Laziness. > Thus, end-users could 'cvsup refuse' the patches for categories > that they do not care about, and it would not break operations > which work on the entire ports collection (such as `make index'). Not that I've tried this, but ... can't you just use a mask like ports/graphics/*/files/ or such to refuse patch files? > So, should we pursue any of this? I like the idea of item c, with the proviso that I added. I wouldn't be=20 so against all of this if you weren't suggesting things that as I=20 understand them would require more work for me to garner information=20 =66rom the ports tree. The whole "all data in one file" idea reminds me=20 of Microsoft for some reason. --=20 I abhor a system designed for the "user", if that word is a coded pejorative meaning "stupid and unsophisticated". -- Ken Thompson - Unix is user friendly. However, it isn't idiot friendly. - Please CC me in all replies, even if I'm on the relevant list(s). --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAskEMk/lo7zvzJioRAvVaAKCQx7h2A3v9Z0L4Ds7RFRrbQpTq2QCfYhTF jZm2WzKCJL0kpD+sDsK+VFI= =XbdV -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy--