On 6/2/08, Loui wrote:

On Mon, 2 Jun 2008 07:19:40 +0200 "Ronald van Haren" wrote:

...

Although as you stated contributing packages is not your primary goal, I suggest you still take another look at your PKGBUILDs and correct the small mistakes that are still in there. If you need help finding them please let me know and I'm happy to point them out.

I'll have a look at those three I still maintain, but I'd be glad to receive pointers as well.

from a quick look: tomatoes: - try to avoid custom variables (_pkgdata). It is not needed and it only appears once. - license is an array - you can use install -Dm755 to install the executable instead of mkdir -p and install (not that what you did is wrong, it's just easier) brlcad: - You can use 'install -Dm' as above for future reference, you can use $srcdir and $pkgdir instead of $startdir/src and $startdir/pkg (of course both work equally well so you can use whatever you like)

On 02/06/2008, at 3:43 PM, Loui wrote:

On Mon, 2 Jun 2008 07:19:40 +0200 "Ronald van Haren" wrote:

...

Although as you stated contributing packages is not your primary goal, I suggest you still take another look at your PKGBUILDs and correct the small mistakes that are still in there. If you need help finding them please let me know and I'm happy to point them out.

I'll have a look at those three I still maintain, but I'd be glad to receive pointers as well.

...

...

Some of my big goals are: - Develop a new system for sharing PKGBUILDs. - Give TUs more direct access and control of that system. - Get every single darn bug closed.

Can you elaborate on these three points (like what kind of system do you have in mind, by bugs you mean AUR bugs or any kind of bugs, etc) ?

- Develop a new system for sharing PKGBUILDs. If you look through the AUR source code it'll become obvious that the design hadn't quite been thought through and the implementation is pretty dodgy. I'm interested in designing a completely new system based on a client-server model. It's a big goal for me that won't be immediatly realised, but I'm just putting the idea out there. I'm kind of working out the client side via aurbuild. aurbuild won't be the client, but I might be able to work out some ideas with it and reuse parts of it.

Are you planning on creating a new web interface and using aurbuild to ease the building of AUR packages, or do you mean something new completely? I'm just wondering if AUR2 would be of any use to you. I most likely going to start up a similar project to AUR, and I'm going to either be using the Archlinux web site code base and extend that or work on making AUR2 more flexible (currently the community/aur repositories are kind of hard coded). I'd like to hear some of your ideas :). Anyway that's a bit off topic. You indeed have few packages, but fortunately that's not all TUs do, and I know that you have an interest in improving AUR and related projects. I agree with Callan and Allan.

- try to avoid custom variables (_pkgdata). It is not needed and it only appears once.

Is that really such a bad thing? I just want to make it clear, since I've been a bit confused about it for a while now. As far as I can tell the only reason not to use custom variables is that the current AUR code base doesn't support them (or maybe it does now?), so URLs and such have unparsed variables in them. Apart from that I don't see any problems with them, as long as it is made sure that they won't conflict with existing package, and using an underscore will do that.

On 03/06/2008, at 1:18 AM, Alessio Bolognino wrote:

On Tue 2008-06-03 01:08, Sebastian Nowicki wrote:

...

On 02/06/2008, at 3:43 PM, Loui wrote:

...

...

- try to avoid custom variables (_pkgdata). It is not needed and it only appears once.

Is that really such a bad thing? I just want to make it clear, since I've been a bit confused about it for a while now. As far as I can tell the only reason not to use custom variables is that the current AUR code base doesn't support them (or maybe it does now?), so URLs and such have unparsed variables in them. Apart from that I don't see any problems with them, as long as it is made sure that they won't conflict with existing package, and using an underscore will do that.

What's the point of using a variable if it never changes and it is used only once?

In this case it's not really necessary, I agree, but I was asking about the general use of "private" variables.

Again, that is where the simplicity/Arch principle comes in. Things happen when and where approriate; making sense of it all. There are 2 primary cases: 1) Traditional reason for variables - shorter alternatives to longer strings 2) Portability/flexibility - other programmers are able to manipulate your code easily (for PKGBUILDS; those editing it) So if the script doesn't have any content relating to (1) or (2) then yet another variable is indeed pointless. We should avoid them unless the benefit is practically significant. Say, for instance, a short PKGBUILD where the source archive's $pkgver != real $pkgver. You are going to submit it to [unsupported] where the AUR web interface cannot resolve custom variables, and the source archive's name has an underscore. You create _pkgver as the new one, and you use it in the source array as ${pkgname}_${_pkgver}, which could do with some cosmetic surgery. Then it'd be up to you to decide whether this new variable, or having a clean look on the web interface, is more beneficial/"important". Since bumping pkgver will not change the source, introducing _pkgver makes it easy to update. At the same time, though, if one is editing the PKGBUILD the source array isn't that many lines down and thus, is as easy as changing the value of a variable. It's a matter of weighing priorities; takes a few seconds before clicking on "submit". In [community] (ABS), this isn't a problem but then - as a TU - you should be able to do the weighing just fine. I don't know if I'm guilty as an [unsupported] user but I sure hope not =P

On Tue, 3 Jun 2008 01:08:43 +0800 Sebastian Nowicki wrote:

On 02/06/2008, at 3:43 PM, Loui wrote:

...

- Develop a new system for sharing PKGBUILDs. If you look through the AUR source code it'll become obvious that the design hadn't quite been thought through and the implementation is pretty dodgy. I'm interested in designing a completely new system based on a client-server model. It's a big goal for me that won't be immediatly realised, but I'm just putting the idea out there. I'm kind of working out the client side via aurbuild. aurbuild won't be the client, but I might be able to work out some ideas with it and reuse parts of it.

Are you planning on creating a new web interface and using aurbuild to ease the building of AUR packages, or do you mean something new completely? I'm just wondering if AUR2 would be of any use to you. I most likely going to start up a similar project to AUR, and I'm going to either be using the Archlinux web site code base and extend that or work on making AUR2 more flexible (currently the community/aur repositories are kind of hard coded). I'd like to hear some of your ideas :).

I'm planning on creating something completely new that doesn't require any web interface, but can use one for convenience. It'll come with command line tools that will be used for full functionality. There are many crazy features that you can add on to it, but that's the basic idea. Something where any hacker can fix bugs, distribute the code and he doesn't have to rely on a central server for everyone to reap the benefits. Where sharing PKGBUILDs can become distributed if desired.