Date: Mon, 24 May 2004 14:38:04 -0400 From: Christopher Nehren <apeiron@comcast.net> To: Garance A Drosihn <drosih@rpi.edu> Cc: freebsd-ports@freebsd.org Subject: Re: Third "RFC" on on pkg-data ideas for ports Message-ID: <20040524183804.GA53827@prophecy.dyndns.org> In-Reply-To: <p0602040dbcd716257540@[128.113.24.47]> References: <p0602040dbcd716257540@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040524183804.GA53827>