[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild

[Donnie Berkholz]

On 18:55 Fri 12 Oct     , Doug Goldstein (cardoe) wrote:
> 1.1                  media-tv/mythtv/mythtv-0.20.2_p14668.ebuild
> 
> file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-tv/mythtv/mythtv-0.20.2_p14668.ebuild?rev=1.1&view=markup
> plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-tv/mythtv/mythtv-0.20.2_p14668.ebuild?rev=1.1&content-type=text/plain

> 	use alsa || myconf="${myconf} --disable-audio-alsa"
> 	use jack || myconf="${myconf} --disable-audio-jack"
> 	use dts || myconf="${myconf} --disable-dts"
> 	use freebox || myconf="${myconf} --disable-freebox"
> 	use dbox2 || myconf="${myconf} --disable-dbox2"
> 	use hdhomerun || myconf="${myconf} --disable-hdhomerun"
> 	use crciprec || myconf="${myconf} --disable-crciprec"
> 	use altivec || myconf="${myconf} --disable-altivec"
> 	use xvmc && myconf="${myconf} --enable-xvmc"
> 	use xvmc && use video_cards_via && myconf="${myconf} --enable-xvmc-pro"
> 	use perl && myconf="${myconf} --with-bindings=perl"
> 	myconf="${myconf}
> 		--disable-audio-arts
> 		$(use_enable lirc)
> 		$(use_enable joystick joystick-menu)
> 		$(use_enable dvb)
> 		--dvb-path=/usr/include
> 		$(use_enable opengl opengl-vsync)
> 		$(use_enable ieee1394 firewire)
> 		--enable-xrandr
> 		--enable-xv
> 		--disable-directfb
> 		--enable-x11
> 		--enable-proc-opt"

How come some of these don't use use_enable()?

> 	cd ${S}/contrib/channel_changers

Some quoting issues like this one.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild

[Doug Goldstein]

Donnie Berkholz wrote:
> On 18:55 Fri 12 Oct     , Doug Goldstein (cardoe) wrote:
>   
>> 1.1                  media-tv/mythtv/mythtv-0.20.2_p14668.ebuild
>>
>> file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-tv/mythtv/mythtv-0.20.2_p14668.ebuild?rev=1.1&view=markup
>> plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-tv/mythtv/mythtv-0.20.2_p14668.ebuild?rev=1.1&content-type=text/plain
>>     
>
>   
>> 	use alsa || myconf="${myconf} --disable-audio-alsa"
>> 	use jack || myconf="${myconf} --disable-audio-jack"
>> 	use dts || myconf="${myconf} --disable-dts"
>> 	use freebox || myconf="${myconf} --disable-freebox"
>> 	use dbox2 || myconf="${myconf} --disable-dbox2"
>> 	use hdhomerun || myconf="${myconf} --disable-hdhomerun"
>> 	use crciprec || myconf="${myconf} --disable-crciprec"
>> 	use altivec || myconf="${myconf} --disable-altivec"
>> 	use xvmc && myconf="${myconf} --enable-xvmc"
>> 	use xvmc && use video_cards_via && myconf="${myconf} --enable-xvmc-pro"
>> 	use perl && myconf="${myconf} --with-bindings=perl"
>> 	myconf="${myconf}
>> 		--disable-audio-arts
>> 		$(use_enable lirc)
>> 		$(use_enable joystick joystick-menu)
>> 		$(use_enable dvb)
>> 		--dvb-path=/usr/include
>> 		$(use_enable opengl opengl-vsync)
>> 		$(use_enable ieee1394 firewire)
>> 		--enable-xrandr
>> 		--enable-xv
>> 		--disable-directfb
>> 		--enable-x11
>> 		--enable-proc-opt"
>>     
>
> How come some of these don't use use_enable()?
>   
Because if you pass the inverse the script blows up. It's ffmpeg's 
configure script that's a hand written script and modified by the MythTV 
developers.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild

[Donnie Berkholz]

On 00:12 Sun 14 Oct     , Doug Goldstein wrote:
> Because if you pass the inverse the script blows up. It's ffmpeg's 
> configure script that's a hand written script and modified by the MythTV 
> developers.

Sigh. Any chance of getting things to move to autotools?

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild

[Steve Long]

Donnie Berkholz wrote:
> On 00:12 Sun 14 Oct     , Doug Goldstein wrote:
>> Because if you pass the inverse the script blows up. It's ffmpeg's
>> configure script that's a hand written script and modified by the MythTV
>> developers.
> 
> Sigh. Any chance of getting things to move to autotools?
> 
Gah not autohell! How about system.mk? All them leet debian bods use
that.. ;)


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild

[Doug Goldstein]

Donnie Berkholz wrote:
> On 00:12 Sun 14 Oct     , Doug Goldstein wrote:
>   
>> Because if you pass the inverse the script blows up. It's ffmpeg's 
>> configure script that's a hand written script and modified by the MythTV 
>> developers.
>>     
>
> Sigh. Any chance of getting things to move to autotools?
>
> Thanks,
> Donnie
>   
Donnie,

In my 4 years of experience with this package and maintaining it and
contributing patches upstream. You don't think I've suggested it? You
don't think I've tweaked this ebuild to work as best as possible for our
users?

I know the other thing I didn't answer was the fact that some variables
aren't quoted. It doesn't matter at all considering their configure
script can't handle spaces in the path names anyway. We've been though
that already. Additionally, qmake can't handle spaces in there even if
you do quote so it really doesn't matter much.

Some of these review changes truly feel like working at a company where
you know the ins and outs of your tool. You can rattle off its
capabilities to a millimeter. A new boss/manager comes in and has no
idea what the tool is or the mission but by god he knows how to do your
job better and you will follow his procedures. It makes no difference if
his steps have no effect on the tool and waste more of your time. You
additionally have to start giving him progress reports on how you're
doing using his procedures, which instantly means you get less work done.

That's what this commits review list feels like.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild

[Jonathan Adamczewski]

Doug Goldstein wrote:
>
> That's what this commits review list feels like.
>   


Nearly every suggestion (from Donnie and others) has been over some
issue that relates directly to either correctness or maintainability. 
It doesn't matter if you can "rattle off capabilities to a millimeter" -
if they're not documented somewhere (like, say, in the comments of the
ebuild) then the maintainer that comes after you gets to go and break it
all over again.


jonathan.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild

[Doug Goldstein]

Jonathan Adamczewski wrote:
> Doug Goldstein wrote:
>   
>> That's what this commits review list feels like.
>>   
>>     
>
>
> Nearly every suggestion (from Donnie and others) has been over some
> issue that relates directly to either correctness or maintainability. 
> It doesn't matter if you can "rattle off capabilities to a millimeter" -
> if they're not documented somewhere (like, say, in the comments of the
> ebuild) then the maintainer that comes after you gets to go and break it
> all over again.
>
>
> jonathan.
>   
Correctness? Fine. Go ahead. Stick $(use_enable xvmc) into the ebuild.
Do it. I dare you. Then try to compile.

Guess what? When it blows up... that's called INcorrect. The opposite of
the right thing.

The maintainer who comes after me would be someone with a experience
with the package. Some bumkin isn't going to come to maintain package
XYZ unless they know or use the package, and guess what? That means
experience.


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 1889 bytes --]

Doug Goldstein <cardoe@gentoo.org>:

> Jonathan Adamczewski wrote:
> > Doug Goldstein wrote:
> >> That's what this commits review list feels like.
> > Nearly every suggestion (from Donnie and others) has been over some
> > issue that relates directly to either correctness or
> > maintainability. It doesn't matter if you can "rattle off
> > capabilities to a millimeter" - if they're not documented somewhere
> > (like, say, in the comments of the ebuild) then the maintainer that
> > comes after you gets to go and break it all over again.
> Correctness? Fine. Go ahead. Stick $(use_enable xvmc) into the ebuild.
> Do it. I dare you. Then try to compile.
> Guess what? When it blows up... that's called INcorrect. The opposite
> of the right thing.

 You were kindly asked if is not possible to use, so why do you feel
attacked?  Do a comment on it and everybody would be fine, even the
people that would have to maintain it some time in the future.  If you
don't like the review process, just ignore it.
 Reviews are not a way to show what kind of idiot the committer is, but
to improve the overall quality of the tree.  Nothing more, nothing less.
 
> The maintainer who comes after me would be someone with a experience
> with the package. Some bumkin isn't going to come to maintain package
> XYZ unless they know or use the package, and guess what? That means
> experience.

 Yes, and the same goes for GNU Emacs, I needed some time to figure out
what all those things did and I broke it several times because I tried
to be clever.  Now we documented it and I think everyone coming after us
will have a less hard time to understand it.  Better document it, you
never know what happens.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild

[Doug Goldstein]

Christian Faulhammer wrote:
> Doug Goldstein <cardoe@gentoo.org>:
>
>   
>> Jonathan Adamczewski wrote:
>>     
>>> Doug Goldstein wrote:
>>>       
>>>> That's what this commits review list feels like.
>>>>         
>>> Nearly every suggestion (from Donnie and others) has been over some
>>> issue that relates directly to either correctness or
>>> maintainability. It doesn't matter if you can "rattle off
>>> capabilities to a millimeter" - if they're not documented somewhere
>>> (like, say, in the comments of the ebuild) then the maintainer that
>>> comes after you gets to go and break it all over again.
>>>       
>> Correctness? Fine. Go ahead. Stick $(use_enable xvmc) into the ebuild.
>> Do it. I dare you. Then try to compile.
>> Guess what? When it blows up... that's called INcorrect. The opposite
>> of the right thing.
>>     
>
>  You were kindly asked if is not possible to use, so why do you feel
> attacked?  Do a comment on it and everybody would be fine, even the
> people that would have to maintain it some time in the future.  If you
> don't like the review process, just ignore it.
>  Reviews are not a way to show what kind of idiot the committer is, but
> to improve the overall quality of the tree.  Nothing more, nothing less.
>   
No. You clearly don't understand where I'm coming from. I think the
commits review is pointless and a waste of resources that could be
better used doing other things. Since commits review is a cyclic process
you will never achieve a perfect state that all developers commit
perfect ebuilds to the tree since new devs come and go. And since we
don't document any of this stuff properly in the devmanual, incoming
devs have to constantly relearn the same lessons that previous incoming
devs learned through the review process. Effective workers work in 4
stages, we're effectively with this approach remaining in stage 1 and
never progressing and admitting we will never progress.

>  
>   
>> The maintainer who comes after me would be someone with a experience
>> with the package. Some bumkin isn't going to come to maintain package
>> XYZ unless they know or use the package, and guess what? That means
>> experience.
>>     
>
>  Yes, and the same goes for GNU Emacs, I needed some time to figure out
> what all those things did and I broke it several times because I tried
> to be clever.  Now we documented it and I think everyone coming after us
> will have a less hard time to understand it.  Better document it, you
> never know what happens.
>
> V-Li
>
>   
Read the ChangeLog. It's there for a reason. It provides valuable
knowledge and information about the package. I would expect any
developer worth their salt to at least brush up on the ChangeLog for any
package they are taking over.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild

[Marijn Schouten (hkBst)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Doug Goldstein wrote:
> Read the ChangeLog. It's there for a reason. It provides valuable
> knowledge and information about the package. I would expect any
> developer worth their salt to at least brush up on the ChangeLog for any
> package they are taking over.

Surely the Changelog is no substitute for good informative comments alongside
the code?

Marijn

- --
Marijn Schouten (hkBst), Gentoo Lisp project
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHFI30p/VmCx0OL2wRAsSEAKDH3RMmMmJCeqIFucwp3KcGnnrQNgCgx7WB
hmBT1S8jmMbPGzpm6BNqqDo=
=MyV4
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild

[Alec Warner]

On 10/15/07, Doug Goldstein <cardoe@gentoo.org> wrote:
> Jonathan Adamczewski wrote:
> > Doug Goldstein wrote:
> >
> >> That's what this commits review list feels like.
> >>
> >>
> >
> >
> > Nearly every suggestion (from Donnie and others) has been over some
> > issue that relates directly to either correctness or maintainability.
> > It doesn't matter if you can "rattle off capabilities to a millimeter" -
> > if they're not documented somewhere (like, say, in the comments of the
> > ebuild) then the maintainer that comes after you gets to go and break it
> > all over again.
> >
> >
> > jonathan.
> >
> Correctness? Fine. Go ahead. Stick $(use_enable xvmc) into the ebuild.
> Do it. I dare you. Then try to compile.
>
> Guess what? When it blows up... that's called INcorrect. The opposite of
> the right thing.
>
> The maintainer who comes after me would be someone with a experience
> with the package. Some bumkin isn't going to come to maintain package
> XYZ unless they know or use the package, and guess what? That means
> experience.

I think this assumption is false.  People maintain packages they don't
know the intricate details of all the time.  You are of course, free
to ignore any and all suggestions offered; but you are not allowed to
silence them.

-Alec
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild

[Doug Goldstein]

Alec Warner wrote:
> On 10/15/07, Doug Goldstein <cardoe@gentoo.org> wrote:
>   
>> Jonathan Adamczewski wrote:
>>     
>>> Doug Goldstein wrote:
>>>
>>>       
>>>> That's what this commits review list feels like.
>>>>
>>>>
>>>>         
>>> Nearly every suggestion (from Donnie and others) has been over some
>>> issue that relates directly to either correctness or maintainability.
>>> It doesn't matter if you can "rattle off capabilities to a millimeter" -
>>> if they're not documented somewhere (like, say, in the comments of the
>>> ebuild) then the maintainer that comes after you gets to go and break it
>>> all over again.
>>>
>>>
>>> jonathan.
>>>
>>>       
>> Correctness? Fine. Go ahead. Stick $(use_enable xvmc) into the ebuild.
>> Do it. I dare you. Then try to compile.
>>
>> Guess what? When it blows up... that's called INcorrect. The opposite of
>> the right thing.
>>
>> The maintainer who comes after me would be someone with a experience
>> with the package. Some bumkin isn't going to come to maintain package
>> XYZ unless they know or use the package, and guess what? That means
>> experience.
>>     
>
> I think this assumption is false.  People maintain packages they don't
> know the intricate details of all the time.  You are of course, free
> to ignore any and all suggestions offered; but you are not allowed to
> silence them.
>
> -Alec
>   
I must have not received my silence/moderate remote control for the
Gentoo mailing lists. Since I haven't received it, I clearly can't
silence anyone on the mailing lists.

I still stand by my original feeling that we'd better the community NOT
only the developers doing the commits by updating the devmanual, which
is accessible to all developers and all users in the Gentoo community.
In addition to updating and cleaning up repoman checks, which is a tool
that everyone in the community can use. This is versus individual
examples in random ebuilds in random e-mails that all have almost an
identical subject on the mailing list.

The commits review is flawed because if we're not documenting this stuff
in one central place, then when new developers join. The same lessons
have to be learned over and over again.

Then again, this depends on the QA guys actually doing something about
the outstanding bugs.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild

[Donnie Berkholz]

On 16:57 Mon 15 Oct     , Doug Goldstein wrote:
> I still stand by my original feeling that we'd better the community NOT
> only the developers doing the commits by updating the devmanual, which
> is accessible to all developers and all users in the Gentoo community.
> In addition to updating and cleaning up repoman checks, which is a tool
> that everyone in the community can use. This is versus individual
> examples in random ebuilds in random e-mails that all have almost an
> identical subject on the mailing list.
> 
> The commits review is flawed because if we're not documenting this stuff
> in one central place, then when new developers join. The same lessons
> have to be learned over and over again.

Doing the review helps us figure out what the common issues are, so we 
actually know what's worth documenting. I've had in mind all along 
getting common issues into docs and into repoman, which is why I wrote 
the original quoting patch.

Also, just because something is documented doesn't mean people do it. 
Furthermore, just because a doc says "write code without bugs" doesn't 
mean people are physically capable of doing so. More eyes on the code 
can never hurt.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild

[Ryan Hill]

Doug Goldstein wrote:
> I still stand by my original feeling that we'd better the community NOT
> only the developers doing the commits by updating the devmanual, which
> is accessible to all developers and all users in the Gentoo community.

This would be a great thing, but I'm under the impression that it's
somewhat difficult to get changes made to the devmanual for various
reasons.  That said I've never actually tried so I'm probably talking
out my ass.

> The commits review is flawed because if we're not documenting this stuff
> in one central place, then when new developers join. The same lessons
> have to be learned over and over again.

I think the review work is already very useful.  However I do agree that
actually documenting this stuff would be even more useful.
 
> Then again, this depends on the QA guys actually doing something about
> the outstanding bugs.

This would not be the least of the various reasons. ;P


-- 
                  fonts / wxWindows / gcc-porting / treecleaners
  EFFD 380E 047A 4B51 D2BD  C64F 8AA8 8346 F9A4 0662 (0xF9A40662)

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild

[Drake Wyrm]

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]

Alec Warner <antarus@gentoo.org> wrote:
> You are of course, free to ignore any and all suggestions offered; but
> you are not allowed to silence them.

:0:
* Subject:.*\[gentoo-dev\].*\[gentoo-commits\]
/dev/null

would neatly ignore the suggestions offered as well as creating relative
silence.

-- 
That is not dead which can eternal lie,
And with strange eons even death may die.
  -- The Call of Cthulu, II. The Tale of Inspector Legrasse

[-- Attachment #2: Type: application/pgp-signature, Size: 206 bytes --]

[gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in media-tv/mythtv: ChangeLog mythtv-0.20.2_p14668.ebuild mythtv-0.21_pre14666.ebuild mythtv-0.21_pre14480-r1.ebuild

[Steve Long]

Doug Goldstein wrote:
> I know the other thing I didn't answer was the fact that some variables
> aren't quoted. It doesn't matter at all considering their configure
> script can't handle spaces in the path names anyway. We've been though
> that already. Additionally, qmake can't handle spaces in there even if
> you do quote so it really doesn't matter much.
>
I disagree: it's important to do the correct thing, wrt spaces in filenames,
in scripts, since there is a well-understood method of doing so (quoting)
and once it is correct, it is always correct no matter what use is made of
it in the future. If upstream tools can't deal with them, then they need to
be fixed. I appreciate that might not happen for this configure script, but
it shoud happen for qmake. (I find it hard to believe that qmake can't deal
with spaces in filenames tbh, not from experience: it just sounds
amateurish.)

> Some of these review changes truly feel like working at a company where
> you know the ins and outs of your tool. You can rattle off its
> capabilities to a millimeter. A new boss/manager comes in and has no
> idea what the tool is or the mission but by god he knows how to do your
> job better and you will follow his procedures. It makes no difference if
> his steps have no effect on the tool and waste more of your time. You
> additionally have to start giving him progress reports on how you're
> doing using his procedures, which instantly means you get less work done.
> 
> That's what this commits review list feels like.

Fair enough: that's how you feel about it. The quoting issue isn't new
though[1]: that it hasn't been picked up on before is no excuse for not
fixing it now, imo. The tool in question is bash, not the upstream
configure script or qmake, and correct usage should be a point of pride:
again, only my opinion.

Then again, no-one's making you report back-- you're not under any
contractual obligation to respond: must just be professional pride? ;-)

[1] http://www.grymoire.com/Unix/Quote.html
http://bash-hackers.org/wiki/doku.php?id=syntax:words explains why and how
the issue arises.


-- 
gentoo-dev@gentoo.org mailing list