[aur-general] [AUR4] Single binary package for different architectures
Hello, I am importing a PKGBUILD for something that has only a binary release. More specifically, a binary release for i686 and another for x86_64. In the old AUR, I was packaging it using an if clause to choose which release to download depending on the architecture -- this way, I can have a single package for both architectures. More or less like this: if [ ${CARCH} = 'x86_64' ]; then source=("http://example.com/release-${pkgver}-x86_64.tar.gz") md5sums=('00112233445566778899aabbccddeeff') else source=("http://example.com/release-${pkgver}-i386.tar.gz") md5sums=('ffeeddccbbaa99887766554433221100') fi Running mksrcinfo fails with the error: /path/PKGBUILD: line XX: [: =: unary operator expected "line XX" points to the line containing the if. Are there some guildelines for packaging something like this? How could I make mksrcinfo work? Is there any way to generate the .SRCINFO file manually to conform to the dual-binary release described above? (or... should I not be doing this at all?) -- Rudy
On Sat, Jun 13, 2015 at 2:31 PM, Rudy Matela <rudy@matela.com.br> wrote:
Hello,
I am importing a PKGBUILD for something that has only a binary release. More specifically, a binary release for i686 and another for x86_64.
In the old AUR, I was packaging it using an if clause to choose which release to download depending on the architecture -- this way, I can have a single package for both architectures. More or less like this:
if [ ${CARCH} = 'x86_64' ]; then source=("http://example.com/release-${pkgver}-x86_64.tar.gz") md5sums=('00112233445566778899aabbccddeeff') else source=("http://example.com/release-${pkgver}-i386.tar.gz") md5sums=('ffeeddccbbaa99887766554433221100') fi
Running mksrcinfo fails with the error:
/path/PKGBUILD: line XX: [: =: unary operator expected
"line XX" points to the line containing the if.
Are there some guildelines for packaging something like this? How could I make mksrcinfo work? Is there any way to generate the .SRCINFO file manually to conform to the dual-binary release described above?
(or... should I not be doing this at all?)
pacman 4.2 introduces source_${CARCH} and *sum_${CARCH} variables. See also: https://wiki.archlinux.org/index.php/PKGBUILD#source
-- Rudy
On Sat, 13 Jun 2015 20:31:08 +0200 Rudy Matela <rudy@matela.com.br> wrote:
if [ ${CARCH} = 'x86_64' ]; then source=("http://example.com/release-${pkgver}-x86_64.tar.gz") md5sums=('00112233445566778899aabbccddeeff') else source=("http://example.com/release-${pkgver}-i386.tar.gz") md5sums=('ffeeddccbbaa99887766554433221100') fi
Running mksrcinfo fails with the error:
/path/PKGBUILD: line XX: [: =: unary operator expected
"line XX" points to the line containing the if.
Are there some guildelines for packaging something like this? How could I make mksrcinfo work?
I do it like that and mksrcinfo works fine: if [ "$CARCH" = "i686" ]; then source=(…) md5sums=(…) elif [ "$CARCH" = "x86_64" ]; then source=(…) md5sums=(…) fi -- Νῖκος Θεοδώρου «Ἀγεωμέτρητος μηδεὶς εἰσίτω!»
On 13/06, Νῖκος Θεοδώρου wrote:
I do it like that and mksrcinfo works fine:
if [ "$CARCH" = "i686" ]; then source=(…) md5sums=(…) elif [ "$CARCH" = "x86_64" ]; then source=(…) md5sums=(…) fi
Even if it works it should not be done anymore. makepkg has had support for architecture-specific sources since 4.2 -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/
On Sat, 13 Jun 2015 22:57:45 +0200 Johannes Löthberg <johannes@kyriasis.com> wrote:
On 13/06, Νῖκος Θεοδώρου wrote:
I do it like that and mksrcinfo works fine:
if [ "$CARCH" = "i686" ]; then source=(…) md5sums=(…) elif [ "$CARCH" = "x86_64" ]; then source=(…) md5sums=(…) fi
Even if it works it should not be done anymore. makepkg has had support for architecture-specific sources since 4.2
Granted, but in my opinion this is cleaner, more structured, I prefer it. -- Νῖκος Θεοδώρου «Ἀγεωμέτρητος μηδεὶς εἰσίτω!»
On 14/06, Νῖκος Θεοδώρου wrote:
On Sat, 13 Jun 2015 22:57:45 +0200 Johannes Löthberg <johannes@kyriasis.com> wrote:
On 13/06, Νῖκος Θεοδώρου wrote:
I do it like that and mksrcinfo works fine:
if [ "$CARCH" = "i686" ]; then source=(…) md5sums=(…) elif [ "$CARCH" = "x86_64" ]; then source=(…) md5sums=(…) fi
Even if it works it should not be done anymore. makepkg has had support for architecture-specific sources since 4.2
Granted, but in my opinion this is cleaner, more structured, I prefer it.
In which way is it cleaner and more structured? It's a bash hack instead of actually using properly structured and supported features. -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/
Hello. Le Sun, 14 Jun 2015 15:51:02 +0200, Johannes Löthberg <johannes@kyriasis.com> a écrit :
In which way is it cleaner and more structured? It's a bash hack instead of actually using properly structured and supported features.
Please take this not-a-bug https://bugs.archlinux.org/task/43714 in consideration, too. It's why i'm not using this structure, personnally: if I did, i'd have to use unique names for each architecture dependant source, and change my package function and/or my build function to take thoses unique names into account. A bash hack inside a bash script is not this bad. -- Rémy Grünblatt Site Monod Tél. : 06.51.74.06.13
On 14/06, Reventlov wrote:
In which way is it cleaner and more structured? It's a bash hack instead of actually using properly structured and supported features.
Please take this not-a-bug https://bugs.archlinux.org/task/43714 in consideration, too.
It's why i'm not using this structure, personnally: if I did, i'd have to use unique names for each architecture dependant source, and change my package function and/or my build function to take thoses unique names into account.
A bash hack inside a bash script is not this bad.
I don't see how that is relevant anymore since the AUR doesn't use sourceballs anymore. -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/
On 14/06, Johannes Löthberg wrote:
On 14/06, Reventlov wrote:
In which way is it cleaner and more structured? It's a bash hack instead of actually using properly structured and supported features.
Please take this not-a-bug https://bugs.archlinux.org/task/43714 in consideration, too.
It's why i'm not using this structure, personnally: if I did, i'd have to use unique names for each architecture dependant source, and change my package function and/or my build function to take thoses unique names into account.
A bash hack inside a bash script is not this bad.
I don't see how that is relevant anymore since the AUR doesn't use sourceballs anymore.
And it will also make it not show up in the AUR properly since the sources won't be parsed properly. -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/
Le 14/06/2015 16:31, Johannes Löthberg a écrit :
On 14/06, Johannes Löthberg wrote:
On 14/06, Reventlov wrote:
In which way is it cleaner and more structured? It's a bash hack instead of actually using properly structured and supported features.
Please take this not-a-bug https://bugs.archlinux.org/task/43714 in consideration, too.
It's why i'm not using this structure, personnally: if I did, i'd have to use unique names for each architecture dependant source, and change my package function and/or my build function to take thoses unique names into account.
A bash hack inside a bash script is not this bad.
I don't see how that is relevant anymore since the AUR doesn't use sourceballs anymore.
And it will also make it not show up in the AUR properly since the sources won't be parsed properly.
I’m not sure to understand you. How would you package this one for instance: https://aur4.archlinux.org/packages/chromium-pepper-flash-standalone/ ? Bruno
On Mon, Jun 22, 2015 at 4:46 PM, Bruno Pagani <bruno.pagani@ens-lyon.org> wrote:
I’m not sure to understand you. How would you package this one for instance:
https://aur4.archlinux.org/packages/chromium-pepper-flash-standalone/
?
Bruno
See this diff: http://pastebin.com/EggVuYpH -- Eli Schwartz
Le 23/06/2015 01:02, Eli Schwartz a écrit :
On Mon, Jun 22, 2015 at 4:46 PM, Bruno Pagani <bruno.pagani@ens-lyon.org> wrote:
I’m not sure to understand you. How would you package this one for instance:
https://aur4.archlinux.org/packages/chromium-pepper-flash-standalone/
?
Bruno
See this diff: http://pastebin.com/EggVuYpH
-- Eli Schwartz
But then: https://bugs.archlinux.org/task/43714
Do this: source_i686=("http://example.com/release-${pkgver}-i386.tar.gz") md5sums_i686=('ffeeddccbbaa99887766554433221100') source_x86_64=("http://example.com/release-${pkgver}-x86_64.tar.gz") md5sums_x86_64=('00112233445566778899aabbccddeeff') package() { local tarball="${source_i686[0]}" [ "$CARCH" == x86_64 ] && tarball="${source_x86_64[0]}" tar xzf "$tarball" "$pkgdir" } This way you're making use of the feature that was introduced to streamline architecture dependency for metadata extraction that is needed for use with the AUR. If you read FS#43714 closely, it says basically what I just said, that the bash functions sometimes have to clean up after the fact that we want to be one set of metadata and the same in all places, on all architectures. Anything else would simply defeat the purpose of compatibility. cheers! mar77i
On 25-06-2015 12:26, Martti Kühne wrote:
Do this:
source_i686=("http://example.com/release-${pkgver}-i386.tar.gz") md5sums_i686=('ffeeddccbbaa99887766554433221100') source_x86_64=("http://example.com/release-${pkgver}-x86_64.tar.gz") md5sums_x86_64=('00112233445566778899aabbccddeeff')
package() { local tarball="${source_i686[0]}" [ "$CARCH" == x86_64 ] && tarball="${source_x86_64[0]}" tar xzf "$tarball" "$pkgdir" }
Wouldn't just local tarball="${source_$CARCH[0]}" or something very similar do the job? -- Mauro Santos
On Thu, 25 Jun 2015 13:17:49 +0100 Mauro Santos <registo.mailling@gmail.com> wrote:
On 25-06-2015 12:26, Martti Kühne wrote:
Do this:
source_i686=("http://example.com/release-${pkgver}-i386.tar.gz") md5sums_i686=('ffeeddccbbaa99887766554433221100') source_x86_64=("http://example.com/release-${pkgver}-x86_64.tar.gz") md5sums_x86_64=('00112233445566778899aabbccddeeff')
package() { local tarball="${source_i686[0]}" [ "$CARCH" == x86_64 ] && tarball="${source_x86_64[0]}" tar xzf "$tarball" "$pkgdir" }
Wouldn't just
local tarball="${source_$CARCH[0]}"
or something very similar do the job?
I believe you need: local tarball=$(eval "echo \${source_${CARCH}[0]}") ...which is complicated enough (and invokes a nice scary eval) that you may as well stick with the conditional. -- Patrick Burroughs (Celti) <celti@celti.name>
On 25/06, Patrick Burroughs wrote:
On Thu, 25 Jun 2015 13:17:49 +0100 Mauro Santos <registo.mailling@gmail.com> wrote:
Wouldn't just
local tarball="${source_$CARCH[0]}"
or something very similar do the job?
I believe you need:
local tarball=$(eval "echo \${source_${CARCH}[0]}")
Why do you believe that? -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/
On Thu, 25 Jun 2015 17:01:02 +0200 Johannes Löthberg <johannes@kyriasis.com> wrote:
On 25/06, Patrick Burroughs wrote:
On Thu, 25 Jun 2015 13:17:49 +0100 Mauro Santos <registo.mailling@gmail.com> wrote:
Wouldn't just
local tarball="${source_$CARCH[0]}"
or something very similar do the job?
I believe you need:
local tarball=$(eval "echo \${source_${CARCH}[0]}")
Why do you believe that?
A quick google and some personal testing showed me that the former doesn't work and the latter does, because bash doesn't interpolate variables in the middle of another variable like that; you need to use eval to make a second pass for it to work. Rather hacky, though, and I see no point in using it over the conditional construct proposed earlier — I just hate to see a suggestion that doesn't work out there. -- Patrick Burroughs (Celti) <celti@celti.name>
On Thu, Jun 25, 2015 at 12:07 PM, Patrick Burroughs <celti@celti.name> wrote:
On Thu, 25 Jun 2015 17:01:02 +0200 Johannes Löthberg <johannes@kyriasis.com> wrote:
On 25/06, Patrick Burroughs wrote:
On Thu, 25 Jun 2015 13:17:49 +0100 Mauro Santos <registo.mailling@gmail.com> wrote:
Wouldn't just
local tarball="${source_$CARCH[0]}"
or something very similar do the job?
I believe you need:
local tarball=$(eval "echo \${source_${CARCH}[0]}")
Why do you believe that?
A quick google and some personal testing showed me that the former doesn't work and the latter does, because bash doesn't interpolate variables in the middle of another variable like that; you need to use eval to make a second pass for it to work. Rather hacky, though, and I see no point in using it over the conditional construct proposed earlier — I just hate to see a suggestion that doesn't work out there.
You'd be better off avoiding the eval and using indirection: local source_array="source_$CARCH" local tarball="${!source_array[0]}"
On 25-06-2015 18:07, Patrick Burroughs (Celti) wrote:
A quick google and some personal testing showed me that the former doesn't work and the latter does, because bash doesn't interpolate variables in the middle of another variable like that; you need to use eval to make a second pass for it to work. Rather hacky, though, and I see no point in using it over the conditional construct proposed earlier — I just hate to see a suggestion that doesn't work out there.
Given that I was the one that suggested something that doesn't work without properly trying it first - sorry about that, how about this one: source_i686=("source1_i686.tar.gz" "source2_i686.tar.gz") md5sums_i686=('md5sum1_i686' 'md5sum2_i686') source_x86_64=("source1_x86_64.tar.gz" "source2_x86_64.tar.gz") md5sums_x86_64=('md5sum1_x86_64' 'md5sum2_x86_64') package() { local -n source="source_$CARCH" tarball="${source[1]}" echo "$tarball" tarball="${source[0]}" echo "$tarball" } CARCH=i686 package CARCH=x86_64 package No evals, but probably requires a quite recent bash version (no problem for arch I suppose). The output should look like: source2_i686.tar.gz source1_i686.tar.gz source2_x86_64.tar.gz source1_x86_64.tar.gz This means you can get any element of the source_{i686,x86_64} array at will via the source variable, this might be useful if there is more than one source in the array. -- Mauro Santos
Sorry, I didn't follow the whole thread, so perhaps this is useless, but maybe not: https://aur.archlinux.org/packages/pa/palemoon-bin/PKGBUILD
On Thu, 25 Jun 2015 20:40:13 +0200, Ralf Mardorf wrote:
Sorry, I didn't follow the whole thread, so perhaps this is useless, but maybe not:
My apologies, now I read the whole thread. I should have done it before sending my mail.
Le 25/06/2015 13:26, Martti Kühne a écrit :
Do this:
source_i686=("http://example.com/release-${pkgver}-i386.tar.gz") md5sums_i686=('ffeeddccbbaa99887766554433221100') source_x86_64=("http://example.com/release-${pkgver}-x86_64.tar.gz") md5sums_x86_64=('00112233445566778899aabbccddeeff')
package() { local tarball="${source_i686[0]}" [ "$CARCH" == x86_64 ] && tarball="${source_x86_64[0]}" tar xzf "$tarball" "$pkgdir" }
This way you're making use of the feature that was introduced to streamline architecture dependency for metadata extraction that is needed for use with the AUR. If you read FS#43714 closely, it says basically what I just said, that the bash functions sometimes have to clean up after the fact that we want to be one set of metadata and the same in all places, on all architectures. Anything else would simply defeat the purpose of compatibility.
cheers! mar77i
Yes, I read that, but this means that you still need a bash hack somewhere in the end (which was my initial point in answer to Johannes)… And the old one looks cleaner IMHO, but I agree that when speaking of metadata, this last one is to be used. The best option would be to get ride of i686. :p
On Thu, 25 Jun 2015 14:18:49 +0200, Bruno Pagani wrote:
The best option would be to get ride of i686. :p
Likely an issue for Arch Linux freaks in Third World nations. Btw. I'm from Germany and still own a "fall-back"-"you-never-know"-32-bit-architecture-mobo. Even my 64-bit architecture computer hardware is outdated. However, AFAIK Ubuntu does not provide i386, even if the packages should be named like that, IIRC they only provide i486, so the time will come when even i686 is history.
Le 25/06/2015 14:26, Ralf Mardorf a écrit :
On Thu, 25 Jun 2015 14:18:49 +0200, Bruno Pagani wrote:
The best option would be to get ride of i686. :p Likely an issue for Arch Linux freaks in Third World nations. Btw. I'm from Germany and still own a "fall-back"-"you-never-know"-32-bit-architecture-mobo. Even my 64-bit architecture computer hardware is outdated.
However, AFAIK Ubuntu does not provide i386, even if the packages should be named like that, IIRC they only provide i486, so the time will come when even i686 is history.
Obviously, and you don’t even have to go so far away: they are still a lot of (often proprietary) packages only 32bit. I was joking. ;)
PS: I guess I still own an unused PC with a Cyrix CPU. Taking a look at the Wiki, it might be that even this Cyrix CPU could belong to the 486 CPUs. My Atari ST has got parallel to the 68000 CPU a 80286 CPU, but I only run TOS and similar and DR DOS on that machine, not Linux ;).
On 25/06, Ralf Mardorf wrote:
However, AFAIK Ubuntu does not provide i386, even if the packages should be named like that, IIRC they only provide i486, so the time will come when even i686 is history.
Linux does not have support for i386 anymore. -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/
On Thu, 25 Jun 2015 17:00:13 +0200, Johannes Löthberg wrote:
On 25/06, Ralf Mardorf wrote:
However, AFAIK Ubuntu does not provide i386, even if the packages should be named like that, IIRC they only provide i486, so the time will come when even i686 is history.
Linux does not have support for i386 anymore.
I didn't know that. However, IIRC a while back there was still i386 support and while Debian did support it, Ubuntu already dropped it.
On 25/06, Ralf Mardorf wrote:
On Thu, 25 Jun 2015 17:00:13 +0200, Johannes Löthberg wrote:
On 25/06, Ralf Mardorf wrote:
However, AFAIK Ubuntu does not provide i386, even if the packages should be named like that, IIRC they only provide i486, so the time will come when even i686 is history.
Linux does not have support for i386 anymore.
I didn't know that. However, IIRC a while back there was still i386 support and while Debian did support it, Ubuntu already dropped it.
Debian dropped i386 support in Debian Sarge[0] in 2005. Ubuntu supposedly dropped[1] it in Ubuntu 10.10 which was released in 2010. That document could be seen as ambiguous though, though I can find several places referencing to it when claiming that it was dropped in 10.10 And last of all, Linux dropped i386 support in 2012. [0] https://www.debian.org/releases/stable/i386/ch02s01.html.en 2.1.2.1 [1]https://help.ubuntu.com/12.04/installation-guide/en.i386/ch02s01.html#idp624... -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/
On Thu, 25 Jun 2015 19:20:30 +0200, Johannes Löthberg wrote:
On 25/06, Ralf Mardorf wrote:
On Thu, 25 Jun 2015 17:00:13 +0200, Johannes Löthberg wrote:
On 25/06, Ralf Mardorf wrote:
However, AFAIK Ubuntu does not provide i386, even if the packages should be named like that, IIRC they only provide i486, so the time will come when even i686 is history.
Linux does not have support for i386 anymore.
I didn't know that. However, IIRC a while back there was still i386 support and while Debian did support it, Ubuntu already dropped it.
Debian dropped i386 support in Debian Sarge[0] in 2005. Ubuntu supposedly dropped[1] it in Ubuntu 10.10 which was released in 2010. That document could be seen as ambiguous though, though I can find several places referencing to it when claiming that it was dropped in 10.10
And last of all, Linux dropped i386 support in 2012.
So I was terrible mistaken :D. I "remember" to read about i386 support of Debian likely after 2005 on the Debian homepage and that time compared it with information about 32-bit architecture by the Ubuntu homepage. However, I'm seemingly mistaken :D. However, the most important information simply is, that "Linux" dropped it in 2012. Without research I believe that you information is correct and my remembrance is wrong. oops ;)
On 25/06, Ralf Mardorf wrote:
On Thu, 25 Jun 2015 19:20:30 +0200, Johannes Löthberg wrote:
On 25/06, Ralf Mardorf wrote:
On Thu, 25 Jun 2015 17:00:13 +0200, Johannes Löthberg wrote:
On 25/06, Ralf Mardorf wrote:
However, AFAIK Ubuntu does not provide i386, even if the packages should be named like that, IIRC they only provide i486, so the time will come when even i686 is history.
Linux does not have support for i386 anymore.
I didn't know that. However, IIRC a while back there was still i386 support and while Debian did support it, Ubuntu already dropped it.
Debian dropped i386 support in Debian Sarge[0] in 2005. Ubuntu supposedly dropped[1] it in Ubuntu 10.10 which was released in 2010. That document could be seen as ambiguous though, though I can find several places referencing to it when claiming that it was dropped in 10.10
And last of all, Linux dropped i386 support in 2012.
So I was terrible mistaken :D. I "remember" to read about i386 support of Debian likely after 2005 on the Debian homepage and that time compared it with information about 32-bit architecture by the Ubuntu homepage. However, I'm seemingly mistaken :D. However, the most important information simply is, that "Linux" dropped it in 2012. Without research I believe that you information is correct and my remembrance is wrong.
Well it doesn't help that Debian still refers to it as i386 in a lot of places. -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/
On Thu, Jun 25, 2015, at 08:26, Martti Kühne wrote:
Do this:
source_i686=("http://example.com/release-${pkgver}-i386.tar.gz") md5sums_i686=('ffeeddccbbaa99887766554433221100') source_x86_64=("http://example.com/release-${pkgver}-x86_64.tar.gz") md5sums_x86_64=('00112233445566778899aabbccddeeff')
package() { local tarball="${source_i686[0]}" [ "$CARCH" == x86_64 ] && tarball="${source_x86_64[0]}" tar xzf "$tarball" "$pkgdir" }
This way you're making use of the feature that was introduced to streamline architecture dependency for metadata extraction that is needed for use with the AUR. If you read FS#43714 closely, it says basically what I just said, that the bash functions sometimes have to clean up after the fact that we want to be one set of metadata and the same in all places, on all architectures. Anything else would simply defeat the purpose of compatibility.
cheers! mar77i
Why not just name them the same locally? source_i686=("$pkgname-$pkgver::http://example.com/release-${pkgver}-i386.tar.gz") md5sums_i686=('ffeeddccbbaa99887766554433221100') source_x86_64=("$pkgname-$pkgver::http://example.com/release-${pkgver}-x86_64.tar.gz") md5sums_x86_64=('00112233445566778899aabbccddeeff') package() { tar xf $pkgname-$pkgver ... } -- Hugo Osvaldo Barrera
On Thu, 25 Jun 2015 12:15:01 -0300 Hugo Osvaldo Barrera <hugo@barrera.io> wrote:
Why not just name them the same locally?
source_i686=("$pkgname-$pkgver::http://example.com/release-${pkgver}-i386.tar.gz") md5sums_i686=('ffeeddccbbaa99887766554433221100') source_x86_64=("$pkgname-$pkgver::http://example.com/release-${pkgver}-x86_64.tar.gz") md5sums_x86_64=('00112233445566778899aabbccddeeff')
package() { tar xf $pkgname-$pkgver ... }
That creates problems verifying the checksums.
On Thu, Jun 25, 2015 at 5:27 PM, Doug Newgard <scimmia@archlinux.info> wrote:
On Thu, 25 Jun 2015 12:15:01 -0300 Hugo Osvaldo Barrera <hugo@barrera.io> wrote:
Why not just name them the same locally?
source_i686=("$pkgname-$pkgver::
http://example.com/release-${pkgver}-i386.tar.gz")
md5sums_i686=('ffeeddccbbaa99887766554433221100') source_x86_64=("$pkgname-$pkgver:: http://example.com/release-${pkgver}-x86_64.tar.gz") md5sums_x86_64=('00112233445566778899aabbccddeeff')
package() { tar xf $pkgname-$pkgver ... }
That creates problems verifying the checksums.
Exactly, read a couple emails back. Also why would you want to decompress the source tarball in the package function? The source for your particular arch, and only that one, is already decompressed by bsdtar, no need for that extra step. See [1] for instance. [1] https://aur4.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=plex-media-server Cheers, -- Maxime
On Thu, Jun 25, 2015, at 12:50, Maxime Gauduin wrote:
On Thu, Jun 25, 2015 at 5:27 PM, Doug Newgard <scimmia@archlinux.info> wrote:
On Thu, 25 Jun 2015 12:15:01 -0300 Hugo Osvaldo Barrera <hugo@barrera.io> wrote:
Why not just name them the same locally?
source_i686=("$pkgname-$pkgver::
http://example.com/release-${pkgver}-i386.tar.gz")
md5sums_i686=('ffeeddccbbaa99887766554433221100') source_x86_64=("$pkgname-$pkgver:: http://example.com/release-${pkgver}-x86_64.tar.gz") md5sums_x86_64=('00112233445566778899aabbccddeeff')
package() { tar xf $pkgname-$pkgver ... }
That creates problems verifying the checksums.
What problems exactly?
Exactly, read a couple emails back. Also why would you want to decompress the source tarball in the package function? The source for your particular arch, and only that one, is already decompressed by bsdtar [...]
I'm aware of this, it was an awful example really. the important bit was really that you wouldn't need to deal with the discrepancies manually. -- Hugo Osvaldo Barrera
Den 26-06-2015 kl. 02:21 skrev Hugo Osvaldo Barrera:
On Thu, Jun 25, 2015, at 12:50, Maxime Gauduin wrote:
On Thu, Jun 25, 2015 at 5:27 PM, Doug Newgard <scimmia@archlinux.info> wrote:
On Thu, 25 Jun 2015 12:15:01 -0300 Hugo Osvaldo Barrera <hugo@barrera.io> wrote:
Why not just name them the same locally?
That creates problems verifying the checksums.
What problems exactly?
If you build both versions (which is the default for `makepkg` IIRC), you will need to delete the downloaded source midway through or makepkg will complain that "$pkgname-$pkgver" (x86_64) doesn't match its checksum (if it downloaded i686 first). Some people also utilise the $SRCDEST setting in makepkg.conf to avoid having to download source files over and over, which is useful if you need to build the same package for several machines. If you happen to have machines of multiple architectures, you will also have to keep deleting the source file to allow makepkg to fetch the architecture one for the machine you're currently building on/for. There are probably more cases where this would clock in. The summary is what Doug originally wrote though. Just Don't Do It™. -- Namasté, Frederik “Freso” S. Olesen <http://freso.dk/> AUR: https://aur.archlinux.org/account/Freso Wiki: https://wiki.archlinux.org/index.php/User:Freso
On 07/07, Frederik “Freso” S. Olesen wrote:
Den 26-06-2015 kl. 02:21 skrev Hugo Osvaldo Barrera:
On Thu, Jun 25, 2015, at 12:50, Maxime Gauduin wrote:
On Thu, Jun 25, 2015 at 5:27 PM, Doug Newgard <scimmia@archlinux.info> wrote:
On Thu, 25 Jun 2015 12:15:01 -0300 Hugo Osvaldo Barrera <hugo@barrera.io> wrote:
Why not just name them the same locally?
That creates problems verifying the checksums.
What problems exactly?
If you build both versions (which is the default for `makepkg` IIRC), you will need to delete the downloaded source midway through or makepkg will complain that "$pkgname-$pkgver" (x86_64) doesn't match its checksum (if it downloaded i686 first).
No, it does not, the 'issue' only applies to making sourceballs and verifying them. -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/
On Tue, Jul 7, 2015 at 5:20 PM, Frederik “Freso” S. Olesen < freso.dk@gmail.com> wrote:
If you build both versions (which is the default for `makepkg` IIRC), you will need to delete the downloaded source midway through or makepkg will complain that "$pkgname-$pkgver" (x86_64) doesn't match its checksum (if it downloaded i686 first).
Why one earth would makepkg *by default* (or ever) build a package for the wrong $arch ? -- Eli Schwartz
On Mon, Jun 22, 2015 at 11:46 PM, Bruno Pagani <bruno.pagani@ens-lyon.org> wrote:
Le 14/06/2015 16:31, Johannes Löthberg a écrit :
On 14/06, Johannes Löthberg wrote:
On 14/06, Reventlov wrote:
In which way is it cleaner and more structured? It's a bash hack instead of actually using properly structured and supported features.
Please take this not-a-bug https://bugs.archlinux.org/task/43714 in consideration, too.
It's why i'm not using this structure, personnally: if I did, i'd have to use unique names for each architecture dependant source, and change my package function and/or my build function to take thoses unique names into account.
A bash hack inside a bash script is not this bad.
I don't see how that is relevant anymore since the AUR doesn't use sourceballs anymore.
And it will also make it not show up in the AUR properly since the sources won't be parsed properly.
I’m not sure to understand you. How would you package this one for instance:
https://aur4.archlinux.org/packages/chromium-pepper-flash-standalone/
?
Bruno
source_i686=("libpepflashplayer-i686-${pkgver}.so::http://docs.volcanis.me/.pepper-flash/i686/libpepflashplayer.so" "manifest-i686-${pkgver}.json::http://docs.volcanis.me/.pepper-flash/i686/manifest.json") sha1sums_i686=('hash1' 'hash2') source_x86_64=("libpepflashplayer-i686-${pkgver}.so::http://docs.volcanis.me/.pepper-flash/x86_64/libpepflashplayer.so" "manifest-x86_64-${pkgver}.json::http://docs.volcanis.me/.pepper-flash/x86_64/manifest.json") sha1sums_x86_64=('hash3' 'hash4') package() { ... install -m 644 libpepflashplayer-$CARCH-${pkgver}.so "${pkgdir}"/usr/lib/PepperFlash/libpepflashplayer.so install -m 644 manifest-$CARCH-${pkgver}.json "${pkgdir}"/usr/lib/PepperFlash/manifest.json ... }
participants (16)
-
Bruno Pagani
-
Buce
-
Doug Newgard
-
Eli Schwartz
-
Frederik “Freso” S. Olesen
-
Hugo Osvaldo Barrera
-
Ido Rosen
-
Johannes Löthberg
-
Martti Kühne
-
Mauro Santos
-
Maxime Gauduin
-
Patrick Burroughs
-
Ralf Mardorf
-
Reventlov
-
Rudy Matela
-
Νῖκος Θεοδώρου