[pacman-dev] [PATCHES] Refreshed PKGBUILDs

Dan McGee dpmcgee at gmail.com
Tue May 20 16:20:22 EDT 2008


Holy long thread batman! I'll chip in a little but looks like this one
has already run most of its course.

On Mon, May 19, 2008 at 6:14 AM, Xavier <shiningxc at gmail.com> wrote:
> On Mon, May 19, 2008 at 12:43 PM, Loui <louipc.ist at gmail.com> wrote:
>> On Mon, 19 May 2008 06:25:36 +0200
>> Geoffroy Carrier <geoffroy.carrier at koon.fr> wrote:
>>
>>> Excerpts from louipc.ist's message of Mon May 19 07:39:45 +0200 2008:
>>> > It would be nice if all three were referenced. I wouldn't feel right if
>>> > $startdir disappeared.
>>> In the .proto files?
>>>
>>
>> Yeah. A prime place to demonstrate all the variables, non?

The *prime* place should be the manpage, not the proto file. Obviously
the proto file should provide a reasonable template, but no need to
clutter it with unnecessary use of $startdir if $srcdir/$pkgdir can
cover it all.

So on that note, we should ensure we have startdir, srcdir, and pkgdir
all documented in PKGBUILD.5. Looks like currently we have none of
these documented.

>
> I actually also see several advantages for not using $startdir :
> 1) pkgdir and srcdir could be independent
> 2) shorter and nicer
> 3) prevents you from accessing files directly from $startdir :
> All files in use need to be put in source array, and these files are
> copied from $startdir to $srcdir.
> So $srcdir has everything you need. If you use $startdir however, you
> can forget to put a file in source array, and you won't notice it
> (that is why namcap prints a warning for that, but you need to use
> namcap :))
>
> and I personally would find it clearer to either use only
> $pkgdir/$srcdir or only $startdir.

I'm with Xavier here. I think we have reached the point where we can
transition to 90% of our usage to being $srcdir/$pkgdir with $startdir
only being used in some very specialized cases. As srcdir/pkgdir were
introduced with 3.1, 3.2 can safely provide default PKGBUILDs using
these variables.

-Dan




More information about the pacman-dev mailing list