[aur-general] [AUR4] Single binary package for different architectures

newer
[aur-general] Merge request for...

older
[aur-general] Signoff report for...

Rudy Matela

13 Jun 2015 13 Jun '15

8:31 p.m.

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

Show replies by date

Ido Rosen

13 Jun 13 Jun

8:36 p.m.

On Sat, Jun 13, 2015 at 2:31 PM, Rudy Matela 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

Νῖκος Θεοδώρου

8:46 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

On Sat, 13 Jun 2015 20:31:08 +0200 Rudy Matela 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 -- Νῖκος Θεοδώρου «Ἀγεωμέτρητος μηδεὶς εἰσίτω!»

Johannes Löthberg

10:57 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

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/

Νῖκος Θεοδώρου

14 Jun 14 Jun

12:34 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

On Sat, 13 Jun 2015 22:57:45 +0200 Johannes Löthberg 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. -- Νῖκος Θεοδώρου «Ἀγεωμέτρητος μηδεὶς εἰσίτω!»

Johannes Löthberg

3:51 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

On 14/06, Νῖκος Θεοδώρου wrote:

...

On Sat, 13 Jun 2015 22:57:45 +0200 Johannes Löthberg 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/

Reventlov

4:19 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

Hello. Le Sun, 14 Jun 2015 15:51:02 +0200, Johannes Löthberg 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

Johannes Löthberg

4:28 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

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/

Johannes Löthberg

4:31 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

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/

Bruno Pagani

22 Jun 22 Jun

11:46 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

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

Eli Schwartz

23 Jun 23 Jun

1:02 a.m.

On Mon, Jun 22, 2015 at 4:46 PM, Bruno Pagani 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

Bruno Pagani

25 Jun 25 Jun

1:02 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

Le 23/06/2015 01:02, Eli Schwartz a écrit :

...

On Mon, Jun 22, 2015 at 4:46 PM, Bruno Pagani 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

Martti Kühne

1:26 p.m.

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

Mauro Santos

2:17 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

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

Patrick Burroughs

2:45 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

On Thu, 25 Jun 2015 13:17:49 +0100 Mauro Santos 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)

Johannes Löthberg

5:01 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

On 25/06, Patrick Burroughs wrote:

...

On Thu, 25 Jun 2015 13:17:49 +0100 Mauro Santos 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/

Patrick Burroughs

7:07 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

On Thu, 25 Jun 2015 17:01:02 +0200 Johannes Löthberg wrote:

...

On 25/06, Patrick Burroughs wrote:

...
On Thu, 25 Jun 2015 13:17:49 +0100 Mauro Santos 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)

Buce

7:24 p.m.

On Thu, Jun 25, 2015 at 12:07 PM, Patrick Burroughs wrote:

...

On Thu, 25 Jun 2015 17:01:02 +0200 Johannes Löthberg wrote:

...
On 25/06, Patrick Burroughs wrote:

...
On Thu, 25 Jun 2015 13:17:49 +0100 Mauro Santos 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]}"

Mauro Santos

8:33 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

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

Ralf Mardorf

8:40 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

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

Ralf Mardorf

9:03 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

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:

https://aur.archlinux.org/packages/pa/palemoon-bin/PKGBUILD

My apologies, now I read the whole thread. I should have done it before sending my mail.

Bruno Pagani

2:18 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

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

Ralf Mardorf

2:26 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

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.

Bruno Pagani

2:30 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

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. ;)

Ralf Mardorf

2:42 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

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 ;).

Johannes Löthberg

5 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

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/

Ralf Mardorf

5:56 p.m.

New subject: [aur-general] [off-topic] [AUR4] Single binary package for different architectures

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.

Johannes Löthberg

7:20 p.m.

New subject: [aur-general] [off-topic] [AUR4] Single binary package for different architectures

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/

Ralf Mardorf

7:48 p.m.

New subject: [aur-general] [off-topic] [AUR4] Single binary package for different architectures

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 ;)

Johannes Löthberg

9:19 p.m.

New subject: [aur-general] [off-topic] [AUR4] Single binary package for different architectures

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/

Hugo Osvaldo Barrera

5:15 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

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

Doug Newgard

5:27 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

On Thu, 25 Jun 2015 12:15:01 -0300 Hugo Osvaldo Barrera 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.

Maxime Gauduin

5:50 p.m.

On Thu, Jun 25, 2015 at 5:27 PM, Doug Newgard wrote:

...

On Thu, 25 Jun 2015 12:15:01 -0300 Hugo Osvaldo Barrera 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

Hugo Osvaldo Barrera

26 Jun 26 Jun

2:21 a.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

On Thu, Jun 25, 2015, at 12:50, Maxime Gauduin wrote:

...

On Thu, Jun 25, 2015 at 5:27 PM, Doug Newgard wrote:

...
On Thu, 25 Jun 2015 12:15:01 -0300 Hugo Osvaldo Barrera 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

Frederik “Freso” S. Olesen

7 Jul 7 Jul

11:20 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

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 wrote:

...
On Thu, 25 Jun 2015 12:15:01 -0300 Hugo Osvaldo Barrera 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

Johannes Löthberg

8 Jul 8 Jul

3:21 p.m.

New subject: [aur-general] [AUR4] Single binary package for different architectures

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 wrote:

...
On Thu, 25 Jun 2015 12:15:01 -0300 Hugo Osvaldo Barrera 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/

Eli Schwartz

4:42 p.m.

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

Maxime Gauduin

25 Jun 25 Jun

6:04 p.m.

On Mon, Jun 22, 2015 at 11:46 PM, Bruno Pagani 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 ... }

3208

Age (days ago)

3233

Last active (days ago)

List overview

Download

37 comments

16 participants

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
Νῖκος Θεοδώρου