Description of the dynamically split packages in AUR

gim · 2014-10-10 19:40:15

Hello! Currently I am the maintainer of the package base phpbb3-i18n and the way PKGBUILD works is by having an array with information about every language pack, based on which it dynamically builds every split package by passing creation of "package()" functions to "eval" utility.

eval "package_$_pkgname() {
    _package $_lang
}"

_package() {
    pkgdesc="$2 Language Pack for phpBB3"
    url="https://www.phpbb.com/customise/db/translation/$4/"
    ...
}

But, unfortunately, it looks like AUR can't figure out that every split package has it's own description and URL. See https://aur.archlinux.org/packages/?K=phpbb3-i18n. It doesn't do any harm though, but still.
Is there a way to fix that without affecting the main idea of the script? Or could it be fixed on the AUR side? Or it's about tarball produced by mkaurball? Thanks.

falconindy · 2014-10-10 21:28:01

See how core/linux does this.

gim · 2014-10-11 07:24:57

falconindy wrote:

See how core/linux does this.

I don't think you understand what's going on here. Linux is in the official binary repository, not AUR. If I put all my packages into binary repo, it would be allright too:

% pacman -Qi phpbb3-i18n-us
Name           : phpbb3-i18n-us
Version        : 3.0.12-3
Description    : American English Language Pack for phpBB3
Architecture   : any
URL            : https://www.phpbb.com/customise/db/translation/1_3_0/
...

As you can see, after the build everything is as it should be (it's own description and URL). The issue is about how "mkaurball" generates a tarball or AUR parsing it.

% pacman -Qs phpbb3-i18n
local/phpbb3-i18n-de 3.0.12-3
    Casual German Language Pack for phpBB3
local/phpbb3-i18n-de-x-formal 3.0.12-3
    Formal German Language Pack for phpBB3
local/phpbb3-i18n-es 3.0.12-3
    Casual Spanish Language Pack for phpBB3
local/phpbb3-i18n-es-ar 3.0.12-3
    Argentinian Spanish Language Pack for phpBB3
local/phpbb3-i18n-es-mx 3.0.12-3
    Mexican Spanish Language Pack for phpBB3
local/phpbb3-i18n-es-x-formal 3.0.12-3
    Formal Spanish Language Pack for phpBB3
local/phpbb3-i18n-fr 3.0.12-3
    French Language Pack for phpBB3
local/phpbb3-i18n-it 3.0.12-3
    Italian Language Pack for phpBB3
local/phpbb3-i18n-nl 3.0.12-3
    Casual Dutch Language Pack for phpBB3
local/phpbb3-i18n-nl-x-formal 3.0.12-3
    Formal Dutch Language Pack for phpBB3
local/phpbb3-i18n-ru 3.0.12-3
    Russian Language Pack for phpBB3
local/phpbb3-i18n-sv 3.0.12-3
    Swedish Language Pack for phpBB3
local/phpbb3-i18n-ua 3.0.12-3
    Ukrainian Language Pack for phpBB3
local/phpbb3-i18n-us 3.0.12-3
    American English Language Pack for phpBB3

Last edited by gim (2014-10-11 07:34:43)

Spider.007 · 2014-10-11 10:22:40

gim wrote:

falconindy wrote:
See how core/linux does this.
I don't think you understand what's going on here. Linux is in the official binary repository, not AUR. If I put all my packages into binary repo, it would be allright too:
[...]

Not sure if this'll fix your issue but the PKGBUILD for the package falconindy refers to can be found here: https://projects.archlinux.org/svntogit … ages/linux

gim · 2014-10-11 10:44:05

Spider.007, It's not helping though. If you're saying that I missed something in my PKGBUILD, then please point what exactly should I add/change there so that AUR could see that every split package has it's own description.

Spider.007 · 2014-10-11 11:40:06

Yeah that's what I said... Anyway; looking at the mkaurball source I think this will be fixed by removing the _package function; moving it's content into the eval like this:

source+=("${_url}/id_${_pkg_id}")
eval "package_$_pkgname() {
   pkgdesc=\"$2 Language Pack for phpBB3\"
   url=\"https://www.phpbb.com/customise/db/translation/$4/\"
   install -d  ${pkgdir}/usr/share/webapps/

   cp -r \$(find "$srcdir/${3}_${4}" -name 'language' -printf '%h\n') ${pkgdir}/usr/share/webapps/phpbb3
}"

Last edited by Spider.007 (2014-10-11 13:57:00)

Lone_Wolf · 2014-10-11 11:40:52

gim,

.AURINFO is just a txt-file holding metadata and can be edited with any texteditor.
Just make the changes you need inside the source tarball, then upload.

To change mkaurball behaviour , try filing a feature / bug reuest against the pkgbuild-introspection package.

gim · 2014-10-11 12:44:01

Spider.007 wrote:

Yeah that's what I said...

No need to be sarcastic. Finding the core/linux tarball source is not a problem. Sorry if my reply sounded a bit rude, I didn't mean to.

Spider.007 wrote:

I think this will be fixed by removing the _package function; moving it's content into the eval

I will try that, thank you for suggestion.

Lone_Wolf wrote:

try filing a feature / bug reuest against the pkgbuild-introspection package

I thought about that, but wanted to make sure that it's not PKGBUILD's bug and I can't do anything about it.

Spider.007 · 2014-10-11 13:44:28

gim wrote:

Spider.007 wrote:
Yeah that's what I said...
No need to be sarcastic. Finding the core/linux tarball source is not a problem. Sorry if my reply sounded a bit rude, I didn't mean to.

You're right, sorry about that. I wasn't sure if you found the core/linux tarball and assumed falconindy was correct about the solution being in there.

gim wrote:

Lone_Wolf wrote:
try filing a feature / bug reuest against the pkgbuild-introspection package
I thought about that, but wanted to make sure that it's not PKGBUILD's bug and I can't do anything about it.

I too doubt this request would be implemented; the introspection package currently works by string-matches on the methods that the PKGBUILD introduces. If it would run the package() method the actual packaging would be attempted; which is unwanted behaviour. The problem is this PKGBUILD introduces the actual package_*() methods only when package() runs; which is why I think the move of code will have a positive effect

falconindy · 2014-10-11 13:45:55

gim wrote:

I don't think you understand what's going on here.

core/linux is an example of a PKGBUILD which generates its package functions dynamically. I'm not sure why you would think this isn't the same scenario (other than assuming that you didn't go read the core/linux PKGBUILD). Inlining the _package function in the eval, as Spider007 suggests, is the right thing to do here.

gim · 2014-10-11 14:10:30

falconindy, I did read that PKGBUILD and yes, it's similar scenario. As I pointed out, the problem is not present for built package (as in case of official repositories where linux is located). I downloaded the tarball and tried to do "mkaurball" on it and it looks like you're right, according to .AURINFO it works there and I should have tried it in the first place.

_package() {
  pkgdesc="The ${pkgbase/linux/Linux} kernel and modules"
  ...
}
_package-headers() {
  pkgdesc="Header files and scripts for building modules for ${pkgbase/linux/Linux} kernel"
  ...
}
_package-docs() {
  pkgdesc="Kernel hackers manual - HTML documentation that comes with the ${pkgbase/linux/Linux} kernel"
  ...
}

pkgname=("${pkgbase}" "${pkgbase}-headers" "${pkgbase}-docs")
for _p in ${pkgname[@]}; do
eval "package_${_p}() {
  $(declare -f "_package${_p#${pkgbase}}")
  _package${_p#${pkgbase}}
}"
done

I still don't quite understand what's the difference between above and this:

eval "package_$_pkgname() {
    _package $_lang
}"

_package() {
    pkgdesc="$2 Language Pack for phpBB3"
    url="https://www.phpbb.com/customise/db/translation/$4/"
    ...
}

Except that in case of core/linux there are three seperate _package* functions, which should not affect that. Or am I wrong? I also tried adding $(declare -f "_package"), same thing.

Last edited by gim (2014-10-11 14:14:07)

falconindy · 2014-10-11 14:21:09

mkaurball's inner workings expect that package() functions will directly contain the package specific overrides. Your PKGBUILD creates package() functions which call some other function, i.e.

package_foo() {
  _package foo bar baz
}

Inlining your _package call results in something like this:

package_foo() {
  pkgdesc="stuff"
  url="more stuff"

  # "_do_package" must not set any attributes like url, depends, pkgdesc, etc
  _do_package foo bar baz
}

mkaurball understands this. In all cases, the PKGBUILD results in the same packages because it's all valid bash, which makepkg happily executes. mkaurball does not execute the package functions, it only tries to extract the package overrides with some regular expressions (see the "funcgrep" function in mkaurball).

Last edited by falconindy (2014-10-11 14:21:37)

gim · 2014-10-11 15:34:53

Now I get it. I appreciate your time!

Awebb · 2014-10-11 20:46:35

Does that mean it works or does that mean you are going to file a bug report?

gim · 2014-10-11 20:47:24

It works, Awebb.

Arch Linux

#1 2014-10-10 19:40:15

Description of the dynamically split packages in AUR

#2 2014-10-10 21:28:01

Re: Description of the dynamically split packages in AUR

#3 2014-10-11 07:24:57

Re: Description of the dynamically split packages in AUR

#4 2014-10-11 10:22:40

Re: Description of the dynamically split packages in AUR

#5 2014-10-11 10:44:05

Re: Description of the dynamically split packages in AUR

#6 2014-10-11 11:40:06

Re: Description of the dynamically split packages in AUR

#7 2014-10-11 11:40:52

Re: Description of the dynamically split packages in AUR

#8 2014-10-11 12:44:01

Re: Description of the dynamically split packages in AUR

#9 2014-10-11 13:44:28

Re: Description of the dynamically split packages in AUR

#10 2014-10-11 13:45:55

Re: Description of the dynamically split packages in AUR

#11 2014-10-11 14:10:30

Re: Description of the dynamically split packages in AUR

#12 2014-10-11 14:21:09

Re: Description of the dynamically split packages in AUR

#13 2014-10-11 15:34:53

Re: Description of the dynamically split packages in AUR

#14 2014-10-11 20:46:35

Re: Description of the dynamically split packages in AUR

#15 2014-10-11 20:47:24

Re: Description of the dynamically split packages in AUR

Board footer