2008/5/17 Xavier :

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.

I agree. $srcdir/$startdir look more nice to me. -- Roman Kyrylych (Роман Кирилич)

On Sat, May 17, 2008 at 3:54 PM, Xavier wrote:

Aaron Griffin wrote:

...

On Sat, May 17, 2008 at 10:28 AM, Geoffroy Carrier wrote:

...

...

...

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

Just to be a tad more technical. I always try to use the ${} syntax when I can. It IS more to type, but prevents errors much more and is a good habit to follow. It's a minor thing, but I prefer that syntax. I don't think we should really enforce it either way

That's interesting. We don't really enforce anything with the prototypes but it's good to show the preferred syntax with them.

I think $pkgname and $pkgver should be safe though, right? They shouldn't contain spaces or other weird things so don't require additional quotings. But pkgdir, srcdir and startdir do.

So maybe instead of : cd "$srcdir/$pkgname-$pkgver" we could use : cd ${srcdir}/$pkgname-$pkgver

Well, ${srcdir} still needs the quotes. "${srcdir}/$pkgname-$pkgver"

Excerpts from shiningxc's message of Sun May 18 11:42:33 +0200 2008:

For some reasons, zsh doesn't seem to need any quoting.. Weird stuff.

No, this shell just has a great expansion. -- Geoffroy Carrier http://gcarrier.koon.fr/

On Sun, May 18, 2008 at 9:20 AM, Miklos Vajna wrote:

On Sat, May 17, 2008 at 09:54:14PM +0200, Xavier wrote:

...

So maybe instead of : cd "$srcdir/$pkgname-$pkgver" we could use : cd ${srcdir}/$pkgname-$pkgver ?

that would be totally illogical. the point of using ${foo} instead of $foo is that in some cases you really need ${foo}:

source=($pkgname_$pkgver) won't work, but source=(${pkgname}_$pkgver) will. (just an example but probably you got the point). because of this, some projects (like gentoo) force the usage of ${foo} everywhere.

OT: I also enforce it in mkinitcpio scripts. It's not a bad idea, just more typing.

On Sun, May 18, 2008 at 6:33 PM, Geoffroy Carrier wrote:

Excerpts from Aaron Griffin's message of Sun May 18 23:43:42 +0200 2008:

...

...

that would be totally illogical. the point of using ${foo} instead of $foo is that in some cases you really need ${foo}:

source=($pkgname_$pkgver) won't work, but source=(${pkgname}_$pkgver) will. (just an example but probably you got the point). because of this, some projects (like gentoo) force the usage of ${foo} everywhere.

OT: I also enforce it in mkinitcpio scripts. It's not a bad idea, just more typing.

I think it's useless. We could also forget about PATH and always use /usr/bin/find... We could also ALWAYS use quotes. Now, should we replace: find . -type f by: "/usr/bin/find" "." "-type" "f" or make light and readable scripts, using the ${} form when necessary?

Um, first off, you *should* use full paths. The rationale has nothing to do with PATHs, but more to do with PATH ordering and things like that. If I'm calling /usr/bin/foobar and happen to have a totally unrelated 'foobar' in a path before /usr/bin, you're going to get stupid results. Additionally, the following will completely cripple non-full path binaries: function grep () { echo "lolfaild" return 1 } Whoops, now all those calls to "grep" are wrong. /bin/grep still works fine. Secondly, quoting everything is just plain stupid. Quoting only needs to be used on variable expansion (or, obviously, hardcoded paths with spaces). So the way your above line SHOULD be used: /usr/bin/find . -type f

On Sun, May 18, 2008 at 7:48 PM, Geoffroy Carrier wrote:

Excerpts from Aaron Griffin's message of Mon May 19 02:08:49 +0200 2008:

...

Um, first off, you *should* use full paths. The rationale has nothing to do with PATHs, but more to do with PATH ordering and things like that.

Are you suggesting we replace every instance of make to use /usr/bin/make?

In that case, I bet 99% of PKGBUILDs are just WRONG. asust % grep -r make /var/abs|wc -l 10835 asust % grep -r /usr/bin/make /var/abs|wc -l 135

Of course, this is completely inaccurate. But I think I've proven my point, even for ABS (let's forget about AUR).

No, I'm not talking about *doing* anything - I am talking about _the right way_ to do something

On Sun, May 18, 2008 at 8:06 PM, Geoffroy Carrier wrote:

Excerpts from Aaron Griffin's message of Mon May 19 02:53:39 +0200 2008:

...

No, I'm not talking about *doing* anything - I am talking about _the right way_ to do something So, maybe if everybody does this wrong and nobody complains about, we should keep this aspect wrong in the PKGBUILD protoypes.

Um, I really think you took this the wrong way, If you look at my original comment, it begins with "OT:". In typical inernet jargon, this means "off topic". My point was an aside. I was not talking about PKGBUILDs at all. I was suggesting nothing - just discussing proper scripting practices.

On Mon, 19 May 2008 03:06:51 +0200 Geoffroy Carrier wrote:

Do we agree on using $srcdir and $pkgdir instead of $startdir in all the protos, as already done on the reference PKGBUILD.proto? Quotes whenever those variables are involded as their absolute path is likely to include spaces?

It would be nice if all three were referenced. I wouldn't feel right if $startdir disappeared. Cheers!

On Mon, 19 May 2008 06:25:36 +0200 Geoffroy Carrier 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?

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 wrote:

On Mon, May 19, 2008 at 12:43 PM, Loui wrote:

...

On Mon, 19 May 2008 06:25:36 +0200 Geoffroy Carrier 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

I don't think white spaces should be a concern. The main idea would be to have a _consistent_ style. Once, I used to do exactly this: $startdir/src/${pkgname}_$pkgname But it could look better. So even if I'm a quarter second slower, I now brace them entirely - consistency (look at kernel26). I don't think about white spaces in paths because that's unlikely; unethical; uncool; a faux pas and the build will fail anyway if there were any (tell me how many of them don't act on a file after navigating into $somedir). ${pkgdir}/foo/bar definitely appeals more than ${startdir}/pkgdir/foo/bar (: I've stuck to that since the first time I noticed it in the proto. However, there are packages like devel ones that need to edit $pkgver so $startdir will still be of use.