[pacman-dev] Libraries for makepkg
What are peoples opinions on adding some libraries to makepkg that would quickly achieve some common tasks (http://bugs.archlinux.org/task/10375)? I think this is a trade of between the ease of interpretation of a single command and understanding what that command actually does. The need to import the function before use makes me lean on the side of including these. If we go for this, I would recommend some fairly strict guidelines on their inclusion. e.g. 1) The function must be a command block in common use or have a good case made for why it will be in the future. 2) The function must be significantly complex so that using it helps with interpretation of the PKGBUILD. I can think of one function which would save a lot of discussion around here: create_desktop_file(<progname>, <description>, <category>) Allan
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 <mcraeallan@hotmail.com> 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 -- Geoffroy Carrier
On Sat, 10 May 2008, Geoffroy Carrier wrote:
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
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. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On 5/10/08, Eric Belanger <belanger@astro.umontreal.ca> 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:
On Sat, May 10, 2008 at 5:16 AM, Allan McRae <mcraeallan@hotmail.com> 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 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)
You are thinking far to hard on this... Just set the icon to have the same name as the binary. Ignore charset issues and translations. If I create a .desktop file manually for the package it never has them anyway. Anything more is the responsibility of upstream.
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 <mcraeallan@hotmail.com> 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
On 10/05/2008, at 11:16 AM, Allan McRae wrote:
What are peoples opinions on adding some libraries to makepkg that would quickly achieve some common tasks (http://bugs.archlinux.org/task/10375)? I think this is a trade of between the ease of interpretation of a single command and understanding what that command actually does. The need to import the function before use makes me lean on the side of including these.
If we go for this, I would recommend some fairly strict guidelines on their inclusion. e.g. 1) The function must be a command block in common use or have a good case made for why it will be in the future. 2) The function must be significantly complex so that using it helps with interpretation of the PKGBUILD.
I can think of one function which would save a lot of discussion around here: create_desktop_file(<progname>, <description>, <category>)
Allan
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
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. -- Sebastian Nowicki
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
Allan McRae wrote:
What are peoples opinions on adding some libraries to makepkg that would quickly achieve some common tasks (http://bugs.archlinux.org/task/10375)? I think this is a trade of between the ease of interpretation of a single command and understanding what that command actually does. The need to import the function before use makes me lean on the side of including these.
If we go for this, I would recommend some fairly strict guidelines on their inclusion. e.g. 1) The function must be a command block in common use or have a good case made for why it will be in the future. 2) The function must be significantly complex so that using it helps with interpretation of the PKGBUILD.
I can think of one function which would save a lot of discussion around here: create_desktop_file(<progname>, <description>, <category>)
I'm always for killing code duplication, so I can't be against that idea :) Though I also got the same feeling that gentoo ebuilds were rather magic and difficult to grasp. But since just looking at the scriptlets would give you the location of libraries (which have to be sourced manually) to look which functions are available and what they do, this seems alright to me.
participants (6)
-
Allan McRae
-
Eric Belanger
-
Geoffroy Carrier
-
R. Dale Thomas
-
Sebastian Nowicki
-
Xavier