[aur-general] TU Application - Ike Devolder

[Ike Devolder]

On Mon, Mar 05, 2012 at 07:51:20AM +1000, Allan McRae wrote:
> On 05/03/12 04:53, Thomas Dziedzic wrote:
> > On Sun, Mar 4, 2012 at 11:48 AM, Xyne <xyne at archlinux.ca> wrote:
> >> Thomas Dziedzic wrote:
> >>
> >>> On Sun, Mar 4, 2012 at 10:47 AM, Thomas Dziedzic <gostrc at gmail.com> wrote:
> >>>> On Sun, Mar 4, 2012 at 10:38 AM, Ike Devolder <ike.devolder at gmail.com> wrote:
> >>>>> Op 03-03-12 16:41, Xyne schreef:
> >>>>>> Ike Devolder wrote:
> >>
> >>>>> Hi Xyne,
> >>>>>
> >>>>> In general i find it a mishap building in folders containing spaces.
> >>>>>
> >>>>> but because it will give a failure here i'm currently updating all my
> >>>>> PKGBUILDs to use the correct quoting, i'm also removing the unneeded ${}
> >>>>>
> >>>>> thx for the note. In the end it is better practice
> >>>>>
> >>>>> --
> >>>>> Ike
> >>>>>
> >>>>
> >>>> IMO, this is all just coding style that doesn't really affect any or 1
> >>>> or 2 people in the whole distro that are insane enough to build with
> >>>> directory names with spaces in them..
> >>>>
> >>>> Since it is coding style, I never judge anyone by it, but ideally
> >>>> would like it closely resembling mine :P
> >>>>
> >>>> I personally hate quoting in pkgbuilds and prefer ${variables} as I
> >>>> find this more readable although I sometimes deviate from this.
> >>>
> >>> Oops, I'm only talking about ${pkgdir}/${srcdir} in here, wasn't specific enough
> >>
> >> There may not be many users who have paths with spaces in them, but they are
> >> perfectly valid. It is very bad practice to write code that fails in valid
> >> situations simply because the coder likes the way the code looks, and it is not
> >> a matter of coding style if it affects the code's behavior.
> >>
> > 
> > In all my years of packaging, never has this been an issue.
> > 
> >> As for Bash variables. there seems to be some common misconception that curly
> >> brackets do something special. They don't. They only provide a way to separate
> >> variables from surrounding text (e.g. ${foo}bar). Including them as a rule
> >> doesn't hurt and it provides consistency, but syntactically they are completely
> >> superfluous in most situations.
> >>
> > 
> > What lead you to believe there is a misconception?
> > Unless this isn't a reply to my previous post then disregard this question.
> > 
> >> Anyway, this isn't a major issue. I just think the argument "but I don't like
> >> the way the valid code looks" is a very bad and lazy one.
> >>
> >> Regards,
> >> Xyne
> > 
> > Nobody really cares.
> > Here's a test, try building all of [core] within a directory with a space in it.
> > Here's a hint, you wont be able to.
> 
> I can guarantee at least 25% of [core] will fail because I hate quoting
> $srcdir/$pkgdir...
> 
> Allan

Well lets stop this discussion about the quoting please!

I'll give my opinion about the issue and then let us close this topic.

I find Xyne's comment valid, especially for AUR, but none the less it is
also valid for the main repos {core,extra,community} (and all testing,
unstable, ... repos). 

Why it has more impact on AUR: you cannot control
what an enduser will be doing, using a helper building in a path with
spaces. So by correct quoting it will introduce a better user experience
for people living with this edgecases. You could say "you should not
build in paths with spaces", but this is no restriction.
AUR should be as robust as possible, so quoting is not a bad thing, this
ensures that in most of the cases one can download the tarball, extract
and run makepkg without any issue.

Concerning the main repo's this is a lesser issue since those packages
are built in a controlled environment. Users using abs are more
experienced and if getting into trouble most will be able to fix it
quickly.

I would also like to call for more respect for each others opinions and
stay away from the "Nobody cares", "it doesnt matter", "hate", ...
Be constructive, help each other, all these harsh comments are brining a
community in a downwards spiral of lesser respect, which could lead in
the end to the decline of this whole distribution. Please don't do that.

-- 
Ike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/aur-general/attachments/20120305/e4a27b40/attachment.asc>