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 ...

[Coleman Kane]

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.
> >>
> > 
> > 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.
> 
> Please don't. Idea to add "long" options to existing "short" ones in 
> base system utilities is very short-sighted. It could look like a cool 
> pet project for somebody learning how to use C ("gee, ma, look, I have 
> made a huge improvement in FreeBSD cp(1) in less than 10 minutes of 
> work"), but in the long run it will hurt us all since sooner or later 
> you will find yourself struggling with scripts that don't work on 
> release X just because it was created on release X+N and therefore uses 
> those cool new long options.
> 
> -Maxim
> 

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. 

Remember, this is supposed to be fun.

-- 
Coleman Kane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20080604/38d46e60/attachment.pgp