From owner-cvs-src@FreeBSD.ORG Wed Jun 4 21:26:01 2008 Return-Path: Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C67731065670; Wed, 4 Jun 2008 21:26:01 +0000 (UTC) (envelope-from cokane@FreeBSD.org) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by mx1.freebsd.org (Postfix) with ESMTP id EE0C18FC1F; Wed, 4 Jun 2008 21:26:00 +0000 (UTC) (envelope-from cokane@FreeBSD.org) Received: from orion.intree.net ([70.62.16.218]) by hrndva-omta06.mail.rr.com with ESMTP id <20080604212600.YWAO18258.hrndva-omta06.mail.rr.com@orion.intree.net>; Wed, 4 Jun 2008 21:26:00 +0000 Received: from mail.cokane.org (unknown [172.31.0.6]) by orion.intree.net (Postfix) with ESMTP id B29EC361C0D3; Wed, 4 Jun 2008 17:25:59 -0400 (EDT) Received: by mail.cokane.org (Postfix, from userid 103) id 7C4D61DB2F9; Wed, 4 Jun 2008 17:25:59 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.1.8-gr1 (2007-02-13) on discordia X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8-gr1 Received: from [172.20.1.3] (erwin.int.cokane.org [172.20.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cokane.org (Postfix) with ESMTP id BD54F16B55B; Wed, 4 Jun 2008 17:25:45 -0400 (EDT) From: Coleman Kane To: Maxim Sobolev In-Reply-To: <4846F520.6040400@FreeBSD.org> References: <200805301426.m4UEQ92d025434@repoman.freebsd.org> <48405C4B.3050603@FreeBSD.org> <1212179252.1967.1.camel@localhost> <20080604041815.GA84027@FreeBSD.org> <20080604043955.GA38627@troutmask.apl.washington.edu> <20080604063631.GA28351@freebie.xs4all.nl> <20080604150013.GA44358@troutmask.apl.washington.edu> <20080604191339.GA31570@freebie.xs4all.nl> <20080604192955.GA46284@troutmask.apl.washington.edu> <1212608575.15220.109.camel@localhost> <4846F520.6040400@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-k7qp4Sx2AVEjvTNeBWn2" Organization: FreeBSD Project Date: Wed, 04 Jun 2008 17:24:23 -0400 Message-Id: <1212614663.15220.136.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 FreeBSD GNOME Team Port Cc: Alexey Dokuchaev , src-committers@FreeBSD.org, Florent Thoumie , cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, Steve Kargl , Wilko Bulte Subject: Re: cvs commit: src/usr.sbin/pkg_install/add main.c pkg_add.1 src/usr.sbin/pkg_install/create main.c pkg_create.1 src/usr.sbin/pkg_install/delete main.c pkg_delete.1 src/usr.sbin/pkg_install/info main.c pkg_info.1 ... X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2008 21:26:02 -0000 --=-k7qp4Sx2AVEjvTNeBWn2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2008-06-04 at 13:03 -0700, Maxim Sobolev wrote: > Coleman Kane wrote: > >> Where do we stop? Should we add long options to all > >> /usr/bin utilities? Why stop at /usr/bin, let's add > >> long options to /usr/sbin, /bin, /sbin, /rescue, etc. > >> > >=20 > > I'm sure if someone has some "add long options to /bin/cp, etc..." > > patches, we can surely discuss them on this list as adults and respect > > the decision to add new features without deprecating any existing > > features, even if we won't be making use of those new features. >=20 > Please don't. Idea to add "long" options to existing "short" ones in=20 > base system utilities is very short-sighted. It could look like a cool=20 > pet project for somebody learning how to use C ("gee, ma, look, I have=20 > made a huge improvement in FreeBSD cp(1) in less than 10 minutes of=20 > work"), but in the long run it will hurt us all since sooner or later=20 > you will find yourself struggling with scripts that don't work on=20 > release X just because it was created on release X+N and therefore uses=20 > those cool new long options. >=20 > -Maxim >=20 It's probably premature to begin shooting that down. I merely picked "cp" as the first tool that came to mind which lives in /bin. Maybe I should have picked on /bin/pax or /usr/bin/lex instead, or something else with 20+ getopt args :P. My point was that it was pretty absurd to start treating this like it will turn into a giant mad party of getopt_long conversions. I don't really have the inclination to go out and add long options to any tool myself, because I have better things to do with my time. As I said earlier, I think it's a better policy to discuss this when the patch/commit comes along, and see what people's feelings are on the matter then. I don't think it is anybody's place at the moment (except maybe core@) to try and deter a committer from making what some feel is a beneficial change to software. Using your argument above about scripts written for release X+1 not working under release X means that the addition of "-a" to /bin/cp should also be reverted, as well as numerous other changes that have happened to CLI tools like ifconfig. There are probably at least 100-or-so different things that change with each .0 release, this is why you have those monstrous case statements in configure scripts. I don't see how it is fair to cherry-pick the getopt_long changes here for these reasons, and chastise someone who's doing good work. Let's just calm down a bit here on this, I seem to have counted at least 6 people (including myself) who either liked it or at least felt that it is up to flz to make that call. Only 2 specifically wanted the commit yanked, and 1 person stated that they didn't like it but didn't state if they wanted it yanked. That sounds like a pretty good start to the decision making process.=20 Remember, this is supposed to be fun. --=20 Coleman Kane --=-k7qp4Sx2AVEjvTNeBWn2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkhHCAQACgkQcMSxQcXat5d0bACeLjg+ektDLT5nl6eMML7s3p6N xa4An2phVPwMNvKKQ9BmVPMh7m7ajX8k =Q1PH -----END PGP SIGNATURE----- --=-k7qp4Sx2AVEjvTNeBWn2--