Date: Wed, 04 Jun 2008 17:24:23 -0400 From: Coleman Kane <cokane@FreeBSD.org> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: Alexey Dokuchaev <danfe@FreeBSD.org>, src-committers@FreeBSD.org, Florent Thoumie <flz@FreeBSD.org>, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, Steve Kargl <sgk@troutmask.apl.washington.edu>, Wilko Bulte <wb@freebie.xs4all.nl> 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 ... Message-ID: <1212614663.15220.136.camel@localhost> In-Reply-To: <4846F520.6040400@FreeBSD.org> References: <200805301426.m4UEQ92d025434@repoman.freebsd.org> <48405C4B.3050603@FreeBSD.org> <1212179252.1967.1.camel@localhost> <a01628140806030818te29e2fet287d59f5ceedfc9c@mail.gmail.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1212614663.15220.136.camel>