[pacman-dev] [PATCHES] Refreshed PKGBUILDs

[Xavier]

Geoffroy Carrier wrote:
> Excerpts from Allan McRae's message of Sat May 17 16:40:41 +0200 2008:
>> It is much better to put patches inline so we can comment on them directly.
> Noticed.
> I'll have to read my mailer's doc deeper.
>
>> I must be missing something here...  where exactly are you changing
>> $srcdir or $pkgdir not to point at $startdir/src and $startdir/pkg? You
>> can have these directories as tmpfs if you really want but how does that
>> need this change?   I also like the use of $startdir/* because it is
>> quite obvious what the startdir is.
> I don't. The whole list I wrote in this mail are rules I think should be
> followed. Not using $srcdir anymore would permit such changes in the
> future.
>

You meant $startdir here right?

I personally like using $srcdir and $pkgdir, mostly because it is 
shorter and I find it nicer too. And it indeed seems to allow more 
flexibility. Also the names are quite explicit so it shouldn't be too 
confusing.
But well, just using these in the prototypes won't convert all existing 
PKGBUILDs. Maybe 1% of the new ones who will be based on these proto..

In any cases, this change was already made in PKGBUILD.proto so it makes 
sense to do it in the other protos in abs package.

>> Quoting paths with variable names seems a good idea.
> Thank you. Except for variables like cvs/svn/etc. paths which are not
> likely to include any spaces or horrible chars. URLs in general are.
>
>>>    - Still, lightweight means smater
>>>      =>  Don't use
>>>        "$_svntrunk" ${something}
>>>         instead of
>>>        $_svntrunk $something
>>>
>> Where exactly is this change?
> This was an example of the rule I wanted to follow... ie. i did not
> introduced quotes of $_svntrunk which obviously won't include spaces.
> (or it's REAAALLY dumb).
>
>> It would be a poorly formed makefile if it did this, but I have struck
>> this once problem before.  It is also readily noticeable when building
>> the package so I'm not sure if this is really needed.
> So did I. I think new packagers which are discovering makepkg are more
> likely to think it's a makepkg problem instead of a wrong Makefile, and
> might not even think about adding the trailing slash.

Well as I said above, I am not so sure how strong the influence of the 
protos is, so what we are discussing here doesn't really matter.
That said, breaking a poorly made makefile is a pretty good feature imo 
:) There are more chances the makefile will be really fixed that way, if 
the packager bothered to report it upstream (which he totally should 
do). And the workaround is easy to make in the few PKGBUILDs who have 
this problem by adding the trailing /
But I would prefer keeping DESTDIR="$pkgdir" in the protos.