On 5/10/08, Eric Belanger  wrote:
> That can be simplified by providing the 3 scripts and adding them to the
>  source array. That is is the recommended way to do this, I beleive.
I see good reasons for both choices.
For files :
 - which use the same pattern
 - distribution-specific
 - that may need to be maintained or adapted to one's system
is seems logical to keep the generation system available in the source package.
And for a case that simple, it seems useless to bundle a bash script
next to the PKGBUILD... Of course, it would make more sense for 5+
scripts instead of 3! (but I now have a code snippet I may reuse)

Please provide your opinion :)

-- 
Geoffroy Carrier

Geoffroy Carrier wrote:

...

I can think of one function which would save a lot of discussion around here: create_desktop_file(<progname>, <description>, <category>) Except I think you need at least to use an icon, and if possible to

On Sat, May 10, 2008 at 5:16 AM, Allan McRae wrote: translate descriptions, that you might get locale issues (charset for the name/description, even for international apps like Prot\'eg\'e I happen to package), etc. Else, seems a good idea :o)

I'd like something that would replace/shorten that (taken from javacc):

for _exe in javacc jjdoc jjtree do cat << EOF > $_exe #!/bin/sh exec /usr/share/java/javacc/bin/$_exe \$@ EOF install -Dm755 $_exe "$pkgdir/usr/bin/$_exe" done

Let me show my stupidity here, but why would a script be: #!/bin/sh exec /usr/share/java/javacc/bin/$_exe \$@ To spawn a shell to start the program, whats wrong with a symlink to the program in its place? ln -s /usr/share/java/javacc/$_exe $pkgdir/usr/bin/$_exe

Sebastian Nowicki wrote:

I'm not sure that I like the idea very much. We should keep away from anything that makes PKGBUILDs more like Gentoo ebuilds. I love the simplicity and, I suppose, explicitness of PKGBUILDs because they are very easy to follow for anyone a bit familiar with shell. This might be nice for some very simple stuff that's tedious, but obvious. Anything that makes PKGBUILDs more cryptic than they currently are is a step backwards, in my opinion. Maybe I haven't created enough packages to see the benefits of this, but Gentoo ebuilds make me sick, and that is the direction I see this going.

I am not a fan of the gentoo ebuild system with functions appearing from nowhere and with no real way of find out what they are doing. But that doesn't mean that makepkg couldn't benifit from some sort of library system. If we take the proposal given in the bug report, you would have to explicitly include the function library you need. e.g. above the build function there would be a line like: source $libdir/create_desktop_file That way when you use the create_desktop_file function, it is quite obvious where it comes from. And it is simple to see the bash equivalent by looking in the sourced file. I am in no way advocating that we go to the extent of the number of functions in the gentoo ebuild system. That is why I said we would need to create some strict guidelines for the inclusion of a function. Perhaps it would be best to create a list of potential functions for inclusion in such a library so we can better judge the trade-off in simplicity/clarity being made with this idea. Allan