Re: [pacman-dev] [PATCHES] Refreshed PKGBUILDs
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.
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. Anyway, It's not something important IMHO. IMHO getting rid of $startdir is.
-- Geoffroy Carrier http://gcarrier.koon.fr/
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.
2008/5/17 Xavier <shiningxc@gmail.com>:
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 (Роман Кирилич)
2008/5/17 Roman Kyrylych <roman.kyrylych@gmail.com>:
2008/5/17 Xavier <shiningxc@gmail.com>:
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.
damn, I meant $srcdir/$pkgdir of course. -- Roman Kyrylych (Роман Кирилич)
On Sat, May 17, 2008 at 10:28 AM, Geoffroy Carrier <geoffroy.carrier@koon.fr> 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
Aaron Griffin wrote:
On Sat, May 17, 2008 at 10:28 AM, Geoffroy Carrier <geoffroy.carrier@koon.fr> 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 ?
On Sat, May 17, 2008 at 3:54 PM, Xavier <shiningxc@gmail.com> wrote:
Aaron Griffin wrote:
On Sat, May 17, 2008 at 10:28 AM, Geoffroy Carrier <geoffroy.carrier@koon.fr> 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"
Travis Willard wrote:
On Sat, May 17, 2008 at 3:54 PM, Xavier<shiningxc@gmail.com> wrote:
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"
Ok what I said was stupid, forget it :) Another thing I just found out, suppose you are in a directory with a space, the following doesn't work in bash but it does work with zsh: startdir=$(pwd); cd $startdir For some reasons, zsh doesn't seem to need any quoting.. Weird stuff.
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 Sat, May 17, 2008 at 09:54:14PM +0200, Xavier <shiningxc@gmail.com> 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. this is not related to spaces, to deal with them, you always need quotes.
On Sun, May 18, 2008 at 9:20 AM, Miklos Vajna <vmiklos@frugalware.org> wrote:
On Sat, May 17, 2008 at 09:54:14PM +0200, Xavier <shiningxc@gmail.com> 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.
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? I think those questions are about do fair things and not make any extreme choice. That's what I think pragmatism is, and what I love in Archlinux. Anyway, it's not my call. -- Geoffroy Carrier http://gcarrier.koon.fr/
On Sun, May 18, 2008 at 6:33 PM, Geoffroy Carrier <geoffroy.carrier@koon.fr> 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
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.
Secondly, quoting everything is just plain stupid. Quoting only needs to be used on variable expansion (or, obviously, hardcoded paths with spaces). I totally agree. I would just exclude cases like $_cvsroot, as spaces are
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). pretty rare in this variable (and the PKGBUILD writer should notice a strange case). -- Geoffroy Carrier http://gcarrier.koon.fr/
On Sun, May 18, 2008 at 7:48 PM, Geoffroy Carrier <geoffroy.carrier@koon.fr> 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
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.
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? My ¢2. -- Geoffroy Carrier http://gcarrier.koon.fr/
On Sun, May 18, 2008 at 8:06 PM, Geoffroy Carrier <geoffroy.carrier@koon.fr> 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.
Excerpts from Aaron Griffin's message of Mon May 19 03:11:23 +0200 2008:
I was suggesting nothing - just discussing proper scripting practices. OK, sorry, I misunderstood you (I don't have much English ML practices). Then I'd say it really depends on the context, but in most case, I totally agree with you. In my practice, on controlled precise environments, I prefer going the PATH way: PATH is then generally predictable (or the person who changed it knows what he's doing), and tweaking the scripts (with functions as you proposed, or with custom binaries), it's easier to do so.
-- Geoffroy Carrier http://gcarrier.koon.fr/
On Mon, 19 May 2008 03:06:51 +0200 Geoffroy Carrier <geoffroy.carrier@koon.fr> 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!
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?
-- Geoffroy Carrier http://gcarrier.koon.fr/
On Mon, 19 May 2008 06:25:36 +0200 Geoffroy Carrier <geoffroy.carrier@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?
On Mon, May 19, 2008 at 12:43 PM, Loui <louipc.ist@gmail.com> wrote:
On Mon, 19 May 2008 06:25:36 +0200 Geoffroy Carrier <geoffroy.carrier@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?
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.
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@gmail.com> wrote:
On Mon, May 19, 2008 at 12:43 PM, Loui <louipc.ist@gmail.com> wrote:
On Mon, 19 May 2008 06:25:36 +0200 Geoffroy Carrier <geoffroy.carrier@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
2008/5/18 Miklos Vajna <vmiklos@frugalware.org>:
On Sat, May 17, 2008 at 09:54:14PM +0200, Xavier <shiningxc@gmail.com> 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.
this is not related to spaces, to deal with them, you always need quotes.
I already said it was stupid, but it is also illogical if you like :) I was just confused. And the fact that it worked with zsh, which is my primary shell, confused me even more. After Travis answer, I remembered it was probably just for separating the variable names. But thanks for confirming this is indeed the main reason.
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.
On Mon, May 19, 2008 at 2:31 PM, Ray Rashif <schivmeister@gmail.com> wrote:
However, there are packages like devel ones that need to edit $pkgver so $startdir will still be of use.
I don't understand what is the problem here. But since you mentioned kernel26, I found one example there: # set correct depmod command for install sed -i -e "s/KERNEL_VERSION=.*/KERNEL_VERSION=${_kernver}/g" $startdir/kernel26.install That is a hack, but it is practical :P Maybe the scriptlet could be simply moved by makepkg to $srcdir like the source files.
participants (9)
-
Aaron Griffin
-
Dan McGee
-
Geoffroy Carrier
-
Loui
-
Miklos Vajna
-
Ray Rashif
-
Roman Kyrylych
-
Travis Willard
-
Xavier