[arch-ports] PKGBUILD and package release thoughts
Alright, here's some discussion about PKGBUILDs and multiple architecture support. We already talked about adding an arch= array to PKGBUILDs. The array would list all the architectures a PKGBUILD is known to build on. I don't think makepkg should stop a package from building on an architecture that isn't listed, but it should at least display a really annoying message warning the user that the package probably won't build properly. The second thing I wanted to talk about is pkgrels. We have a problem in that some releases will only affect one architecture and we don't want people using other architectures to have to download packages that haven't changed. My proposal goes something like this: We continue using the pkgrel variable the same way. Each time an update (that isn't a version update) happens to a package, its pkgrel is increased. We also add support to makepkg for a couple more variables. Let's call them pkgrel_i686, pkgrel_amd64, etc. If one of these variables exists, makepkg (and gensync, and updatesync...) will us that pkgrel for the architecture, instead of the pkgrel. What this lets us do is something like this: Package foo is at version 1.2.3-1. A change that only affects i686 happens, so the package maintainer makes the changes (marking them with [ "$CARCH" = "i686" ] && ), updates the pkgrel to 2, and sets pkgrel_i686=2 and leaves all the other variables (pkgrel_amd64, etc) set to 1. When you build the package on i686, it comes out as 1.2.3-2. If you build it on any of the other listed architectures, it comes out as 1.2.3-1. This does mean that if there's a release for all architectures, it becomes -3 everywhere and amd64 users see a jump from -1 to -3. We already have a similar situation with the testing repo. Using this method we can target changes for different architectures all while keeping a single PKGBUILD. There are very few changes needed in makepkg and the other tools to cover all the upgrade cases that I can think of. Thoughts? Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.
Jason Chu schrieb:
We also add support to makepkg for a couple more variables. Let's call them pkgrel_i686, pkgrel_amd64, etc. If one of these variables exists, makepkg (and gensync, and updatesync...) will us that pkgrel for the architecture, instead of the pkgrel.
What this lets us do is something like this:
Package foo is at version 1.2.3-1. A change that only affects i686 happens, so the package maintainer makes the changes (marking them with [ "$CARCH" = "i686" ] && ), updates the pkgrel to 2, and sets pkgrel_i686=2 and leaves all the other variables (pkgrel_amd64, etc) set to 1.
When you build the package on i686, it comes out as 1.2.3-2. If you build it on any of the other listed architectures, it comes out as 1.2.3-1.
This does mean that if there's a release for all architectures, it becomes -3 everywhere and amd64 users see a jump from -1 to -3. We already have a similar situation with the testing repo.
Do we really need more variables? Why not leave only one pkgrel number e.g. foo 1.0-1. If the x86_64 bit package needs a fix we would build only a 1.0-2 on x86_64 and let out not affected architectures. Next common release would be 1.0-3 for all archs. Is it possible that way? And maybe you should start in another mail the svn/cvs war again ;-) AndyRTR
Do we really need more variables? Why not leave only one pkgrel number e.g. foo 1.0-1. If the x86_64 bit package needs a fix we would build only a 1.0-2 on x86_64 and let out not affected architectures. Next common release would be 1.0-3 for all archs.
Is it possible that way?
In the interest of keeping a single common PKGBUILD it sounds like Jason's solution would be the best, since it lets gensync/updatesync detect and pull the needed updates automatically. (If I understand correctly.) I don't even use ABS so I should probably shut-up, but since you asked . . . . . :) Maluvia
Would it be possible to use an array (or dict ;-)) of architecture releases instead of multiple variables? This would restrict it to one line in the PKGBUILD. I guess we could also have convention of semi-colon separating the arch-pkg-rel variables to conserve space. Really don't like how long these things are getting... :( Dusty On 3/10/06, Maluvia <terakuma@imbris.net> wrote:
Do we really need more variables? Why not leave only one pkgrel number e.g. foo 1.0-1. If the x86_64 bit package needs a fix we would build only a 1.0-2 on x86_64 and let out not affected architectures. Next common release would be 1.0-3 for all archs.
Is it possible that way?
In the interest of keeping a single common PKGBUILD it sounds like Jason's solution would be the best, since it lets gensync/updatesync detect and pull the needed updates automatically. (If I understand correctly.) I don't even use ABS so I should probably shut-up, but since you asked . . . . . :)
Maluvia
_______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports
On Fri, Mar 10, 2006 at 06:43:14PM -0500, Dusty Phillips wrote:
Would it be possible to use an array (or dict ;-)) of architecture releases instead of multiple variables? This would restrict it to one line in the PKGBUILD. I guess we could also have convention of semi-colon separating the arch-pkg-rel variables to conserve space. Really don't like how long these things are getting... :(
Dusty
Something like that would require parsing. Bash doesn't support any sort of associative arrays, so we'd end up doing something like how depends version marking works ie. arch_rels=('i686=3' 'amd64=2') Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.
I appreciate the goal of joining multiple architectures into a single pkgbuild, but I haven't heard much (at least that I remember) lately about how pkgbuilds with different build requirements based on architecture are going to be handled. Are there going to be seperate "build" definitions, based upon architecture? i686_build() ppc_build() or is there going to be some type of variable testing inside a single build defintion... build() { if [ $ARCHx = "i696x" ]; then <custom stuff here> fi } Also, would there be seperate file sections? If one architecture requires a patch that another one doesn't, are all files fetched for build regardless? I suppose I am saying that a little more background into how the overall structure is going to work, may help make informed opinions about versioning conventions. I apologize if I missed the discussion of the above, and this has already been covered.
On Fri, Mar 10, 2006 at 06:43:14PM -0500, Dusty Phillips wrote:
Would it be possible to use an array (or dict ;-)) of architecture releases instead of multiple variables? This would restrict it to one line in the PKGBUILD. I guess we could also have convention of semi-colon separating the arch-pkg-rel variables to conserve space. Really don't like how long these things are getting... :(
Dusty
Something like that would require parsing. Bash doesn't support any sort of associative arrays, so we'd end up doing something like how depends version marking works ie.
arch_rels=('i686=3' 'amd64=2')
Jason
-- If you understand, things are just as they are. If you do not understand, things are just as they are. _______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports
All your questions should be answered here: http://www.archlinux.org/pipermail/arch-ports/2006-February/000112.html Both the build() and any source=() changes can happen with [ ] style testing. This is bash after all ;) Jason On Fri, Mar 10, 2006 at 04:46:28PM -0800, eliott@cactuswax.net wrote:
I appreciate the goal of joining multiple architectures into a single pkgbuild, but I haven't heard much (at least that I remember) lately about how pkgbuilds with different build requirements based on architecture are going to be handled.
Are there going to be seperate "build" definitions, based upon architecture? i686_build() ppc_build()
or is there going to be some type of variable testing inside a single build defintion... build() { if [ $ARCHx = "i696x" ]; then <custom stuff here> fi }
Also, would there be seperate file sections? If one architecture requires a patch that another one doesn't, are all files fetched for build regardless?
I suppose I am saying that a little more background into how the overall structure is going to work, may help make informed opinions about versioning conventions.
I apologize if I missed the discussion of the above, and this has already been covered.
On Fri, Mar 10, 2006 at 06:43:14PM -0500, Dusty Phillips wrote:
Would it be possible to use an array (or dict ;-)) of architecture releases instead of multiple variables? This would restrict it to one line in the PKGBUILD. I guess we could also have convention of semi-colon separating the arch-pkg-rel variables to conserve space. Really don't like how long these things are getting... :(
Dusty
Something like that would require parsing. Bash doesn't support any sort of associative arrays, so we'd end up doing something like how depends version marking works ie.
arch_rels=('i686=3' 'amd64=2')
Jason
-- If you understand, things are just as they are. If you do not understand, things are just as they are. _______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports
_______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports
-- If you understand, things are just as they are. If you do not understand, things are just as they are.
I think Xentac's suggestion is simple enough..but do we really need to have the original "pkgrel" variable when we have the new pkgrel_i686 and pkgrel_amd64? What purpose does the original "pkgrel" variable serve when the final package release number does not depend on it? ganja_guru Jason Chu wrote:
All your questions should be answered here:
http://www.archlinux.org/pipermail/arch-ports/2006-February/000112.html
Both the build() and any source=() changes can happen with [ ] style testing. This is bash after all ;)
Jason
On Fri, Mar 10, 2006 at 04:46:28PM -0800, eliott@cactuswax.net wrote:
I appreciate the goal of joining multiple architectures into a single pkgbuild, but I haven't heard much (at least that I remember) lately about how pkgbuilds with different build requirements based on architecture are going to be handled.
Are there going to be seperate "build" definitions, based upon architecture? i686_build() ppc_build()
or is there going to be some type of variable testing inside a single build defintion... build() { if [ $ARCHx = "i696x" ]; then <custom stuff here> fi }
Also, would there be seperate file sections? If one architecture requires a patch that another one doesn't, are all files fetched for build regardless?
I suppose I am saying that a little more background into how the overall structure is going to work, may help make informed opinions about versioning conventions.
I apologize if I missed the discussion of the above, and this has already been covered.
On Sat, Mar 11, 2006 at 10:13:59AM +0530, ganja.guru wrote:
I think Xentac's suggestion is simple enough..but do we really need to have the original "pkgrel" variable when we have the new pkgrel_i686 and pkgrel_amd64? What purpose does the original "pkgrel" variable serve when the final package release number does not depend on it?
ganja_guru
If an arch isn't listed, it'll use the pkgrel. Only if a change doesn't affect something does it get its own pkgrel variable. It also helps to have a global pkgrel that everything stays in sync with. Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.
On Sat, Mar 11, 2006 at 12:05:06AM +0100, Andreas Radke wrote:
Jason Chu schrieb:
We also add support to makepkg for a couple more variables. Let's call them pkgrel_i686, pkgrel_amd64, etc. If one of these variables exists, makepkg (and gensync, and updatesync...) will us that pkgrel for the architecture, instead of the pkgrel.
What this lets us do is something like this:
Package foo is at version 1.2.3-1. A change that only affects i686 happens, so the package maintainer makes the changes (marking them with [ "$CARCH" = "i686" ] && ), updates the pkgrel to 2, and sets pkgrel_i686=2 and leaves all the other variables (pkgrel_amd64, etc) set to 1.
When you build the package on i686, it comes out as 1.2.3-2. If you build it on any of the other listed architectures, it comes out as 1.2.3-1.
This does mean that if there's a release for all architectures, it becomes -3 everywhere and amd64 users see a jump from -1 to -3. We already have a similar situation with the testing repo.
Do we really need more variables? Why not leave only one pkgrel number e.g. foo 1.0-1. If the x86_64 bit package needs a fix we would build only a 1.0-2 on x86_64 and let out not affected architectures. Next common release would be 1.0-3 for all archs.
Is it possible that way?
And maybe you should start in another mail the svn/cvs war again ;-)
AndyRTR
My problem with that is that you really depend on your version control to give you the right versions for each architecture and keeping them in sync becomes difficult again. It's possible, but with the more-variables method you could take either PKGBUILD and get the same output on amd64. With yours, I'd get this amd64 -2 version that never actually existed. Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.
Jason Chu schrieb:
Alright, here's some discussion about PKGBUILDs and multiple architecture support. What about having different sources?
For the kernels I can imagine a config_x86/config_ppc/config_x86_64 file. But there are packages with huge arch specific sources like j2re, jsdk, nvidia and some others. Can this be done by the bash [ ] or how else? And how will makepkg decide what sources to download and md5sum are the correct checksums? Maybe we need source_x64_64 and md5sums_x86_64? AndyRTR
On Sat, Mar 11, 2006 at 08:36:23AM +0100, Andreas Radke wrote:
Jason Chu schrieb:
Alright, here's some discussion about PKGBUILDs and multiple architecture support. What about having different sources?
For the kernels I can imagine a config_x86/config_ppc/config_x86_64 file. But there are packages with huge arch specific sources like j2re, jsdk, nvidia and some others.
Can this be done by the bash [ ] or how else?
And how will makepkg decide what sources to download and md5sum are the correct checksums? Maybe we need source_x64_64 and md5sums_x86_64?
AndyRTR
If there is that large of a discrepency (like j2re, from what I understand), it will be a whole different package: j2re-amd64. If there are just patches and things like that it will look something like this: source=('sources' 'that' 'are' 'common') [ "$CARCH" = "amd64" ] && source=(${source[@]} 'other' 'source') Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.
If there is that large of a discrepency (like j2re, from what I understand), it will be a whole different package: j2re-amd64.
Jason
Side note: Don't we want to call it something besides amd64 since it *should* probably work on emt64 Intels? x86_64 ?
Dale Blount schrieb:
If there is that large of a discrepency (like j2re, from what I understand), it will be a whole different package: j2re-amd64.
Jason
Side note: Don't we want to call it something besides amd64 since it *should* probably work on emt64 Intels? x86_64 ?
_______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports
Sure. The 64bit dev always use x86_64 or x64. AndyRTR
Jason Chu schrieb:
If there is that large of a discrepency (like j2re, from what I understand), it will be a whole different package: j2re-amd64.
If there are just patches and things like that it will look something like this: source=('sources' 'that' 'are' 'common') [ "$CARCH" = "amd64" ] && source=(${source[@]} 'other' 'source')
Jason
------------------------------------------------------------------------
_______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports
Here is my latest pkgbuild for j2re. I don't know how to prevent makepkg downloading the large 32bit source. But only therefor a different package? # $Id: PKGBUILD,v 1.15 2006/02/11 23:04:29 jgc Exp $ # Contributed by: Jason Chu <jason@archlinux.org> # This PKGBUILD was built largely from code in Crux Linux, then modified a bunch to make it j2re # Maintainer: Jason Chu <jason@archlinux.org> # Contributions by Dusty pkgname=j2re pkgver=1.5.0_06 pkgrel=3 pkgdesc="Sun's java runtime environment" url="http://java.sun.com" depends=('gcc' 'glibc') install="j2re.install" #source=(http://public.planetmirror.com/pub/java-sun/J2SE/5.0_04/linux32/jre-1_5_0_04... j2re.profile jre.patch) #source=(http://mirror.dcc.fc.up.pt/Java/jre-1_5_0_06-linux-i586.bin j2re.profile jre.patch) [ "$CARCH" == "x86_64" ] && source=(http://mirror.dcc.fc.up.pt/Java/jre-1_5_0_06-linux-amd64.bin j2re.profile jre.patch) md5sums=('e0a88dbec9bfe3195794bb652bfc6516' '87d90b2e075b77c41a7efec7411a4153'\ '3b589fa777fab553d4f7ce57bc90ce48') [ "$CARCH" == "x86_64" ] && md5sums=('6a771c3c9e93021ab34a30bcf609c74b' '87d90b2e075b77c41a7efec7411a4153'\ '91544f3d5d5aa054db7ce2144d17138b') build() { cd $startdir/src [ "$CARCH" == "i686" ] && patch -p0 jre-1_5_0_06-linux-i586.bin <jre.patch [ "$CARCH" == "x86_64" ] && patch -p0 jre-1_5_0_06-linux-amd64.bin <jre.patch mkdir -p $startdir/pkg/opt/java cd $startdir/pkg/opt/java [ "$CARCH" == "i686" ] && echo -e "q\nyes" | sh $startdir/src/jre-1_5_0_06-linux-i586.bin [ "$CARCH" == "x86_64" ] && echo -e "q\nyes" | sh $startdir/src/jre-1_5_0_06-linux-amd64.bin mv jre${pkgver} jre rm -r jre/man/ja* for i in jre/*; do if [ -f $i ]; then rm -f $i; fi done install -D -m755 $startdir/src/${pkgname}.profile $startdir/pkg/etc/profile.d/${pkgname}.sh # no plugin for x86_64 if [ "$CARCH" == "i686" ]; then mkdir -p $startdir/pkg/opt/mozilla/lib/plugins ln -s /opt/java/jre/plugin/i386/ns7/libjavaplugin_oji.so $startdir/pkg/opt/mozilla/lib/plugins else echo "no plugin for x86_64" fi } Something to improve? AndyRTR
On Sat, Mar 11, 2006 at 09:37:09PM +0100, Andreas Radke wrote:
Jason Chu schrieb:
If there is that large of a discrepency (like j2re, from what I understand), it will be a whole different package: j2re-amd64.
If there are just patches and things like that it will look something like this: source=('sources' 'that' 'are' 'common') [ "$CARCH" = "amd64" ] && source=(${source[@]} 'other' 'source')
Jason
------------------------------------------------------------------------
_______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports
Here is my latest pkgbuild for j2re. I don't know how to prevent makepkg downloading the large 32bit source. But only therefor a different package?
# $Id: PKGBUILD,v 1.15 2006/02/11 23:04:29 jgc Exp $ # Contributed by: Jason Chu <jason@archlinux.org> # This PKGBUILD was built largely from code in Crux Linux, then modified a bunch to make it j2re # Maintainer: Jason Chu <jason@archlinux.org> # Contributions by Dusty
pkgname=j2re pkgver=1.5.0_06 pkgrel=3 pkgdesc="Sun's java runtime environment" url="http://java.sun.com" depends=('gcc' 'glibc') install="j2re.install"
Rather than these lines,
#source=(http://public.planetmirror.com/pub/java-sun/J2SE/5.0_04/linux32/jre-1_5_0_04... j2re.profile jre.patch) #source=(http://mirror.dcc.fc.up.pt/Java/jre-1_5_0_06-linux-i586.bin j2re.profile jre.patch) [ "$CARCH" == "x86_64" ] && source=(http://mirror.dcc.fc.up.pt/Java/jre-1_5_0_06-linux-amd64.bin j2re.profile jre.patch) md5sums=('e0a88dbec9bfe3195794bb652bfc6516' '87d90b2e075b77c41a7efec7411a4153'\ '3b589fa777fab553d4f7ce57bc90ce48') [ "$CARCH" == "x86_64" ] && md5sums=('6a771c3c9e93021ab34a30bcf609c74b' '87d90b2e075b77c41a7efec7411a4153'\ '91544f3d5d5aa054db7ce2144d17138b')
I would probably do it like this: source=(j2re.profile jre.patch) md5sums=('87d90b2e075b77c41a7efec7411a4153' '3b589fa777fab553d4f7ce57bc90ce48') [ "$CARCH" = "i686" ] && source=(http://public.planetmirror.com/pub/java-sun/J2SE/5.0_04/linux32/jre-1_5_0_04... ${source[@]}) [ "$CARCH" = "i686" ] && md5sums=('e0a88dbec9bfe3195794bb652bfc6516' ${md5sums[@]}) [ "$CARCH" = "x86_64" ] && source=(http://mirror.dcc.fc.up.pt/Java/jre-1_5_0_06-linux-amd64.bin ${source[@]}) [ "$CARCH" = "x86_64" ] && md5sums=('6a771c3c9e93021ab34a30bcf609c74b' ${md5sums[@]}) And considering below, how you continually repeat jre-1_5_0_06-linux-i586.bin and jre-1_5_0_06-linux-amd64.bin, I would suggest a variable at the top called _binname, set like this: [ "$CARCH" = "i686" ] && _binname='jre-1_5_0_04-linux-i586.bin' [ "$CARCH" = "x86_64" ] && _binname='jre-1_5_0_06-linux-amd64.bin' And then every time you have a [ "$CARCH" = "i686" ] && line where the only difference is the filename, replace it like this:
build() { cd $startdir/src [ "$CARCH" == "i686" ] && patch -p0 jre-1_5_0_06-linux-i586.bin <jre.patch [ "$CARCH" == "x86_64" ] && patch -p0 jre-1_5_0_06-linux-amd64.bin <jre.patch
patch -p0 $_binname <jre.patch
mkdir -p $startdir/pkg/opt/java cd $startdir/pkg/opt/java [ "$CARCH" == "i686" ] && echo -e "q\nyes" | sh $startdir/src/jre-1_5_0_06-linux-i586.bin [ "$CARCH" == "x86_64" ] && echo -e "q\nyes" | sh $startdir/src/jre-1_5_0_06-linux-amd64.bin
echo -e "q\nyes" | sh $startdir/src/$_binname
mv jre${pkgver} jre rm -r jre/man/ja* for i in jre/*; do if [ -f $i ]; then rm -f $i; fi done install -D -m755 $startdir/src/${pkgname}.profile $startdir/pkg/etc/profile.d/${pkgname}.sh
# no plugin for x86_64 if [ "$CARCH" == "i686" ]; then mkdir -p $startdir/pkg/opt/mozilla/lib/plugins ln -s /opt/java/jre/plugin/i386/ns7/libjavaplugin_oji.so $startdir/pkg/opt/mozilla/lib/plugins else echo "no plugin for x86_64"
What is this else doing here? The only person who will see that is the builder and I don't know that they would care...
fi }
Something to improve?
AndyRTR
You can also replace the filenames in the new source lines I gave with $_binname, if you wanted to. How's that for improvement? Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.
These builds are starting to look very un-KISS. Approximately what percentage of PKGBUILDs are going to require architecture-specific code like this? Perhaps it would be better to store multiple versions of the PKGBUILD after all --ie: PKGBUILD-i686 PKGBUILD-x86_64 in the abs directory. This would be a pain when updating duplicate code in each PKGBUILD, but the overall look per PKGBUILD would be far more elegant. It depends how often there is going to be a problem. Perhaps its just ugly bash syntax and we should think about doing PKGBUILDs in Python. Yeah, I wish too. Dusty On 3/11/06, Jason Chu <jason@archlinux.org> wrote:
On Sat, Mar 11, 2006 at 09:37:09PM +0100, Andreas Radke wrote:
Jason Chu schrieb:
If there is that large of a discrepency (like j2re, from what I understand), it will be a whole different package: j2re-amd64.
If there are just patches and things like that it will look something like this: source=('sources' 'that' 'are' 'common') [ "$CARCH" = "amd64" ] && source=(${source[@]} 'other' 'source')
Jason
------------------------------------------------------------------------
_______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports
Here is my latest pkgbuild for j2re. I don't know how to prevent makepkg downloading the large 32bit source. But only therefor a different package?
# $Id: PKGBUILD,v 1.15 2006/02/11 23:04:29 jgc Exp $ # Contributed by: Jason Chu <jason@archlinux.org> # This PKGBUILD was built largely from code in Crux Linux, then modified a bunch to make it j2re # Maintainer: Jason Chu <jason@archlinux.org> # Contributions by Dusty
pkgname=j2re pkgver=1.5.0_06 pkgrel=3 pkgdesc="Sun's java runtime environment" url="http://java.sun.com" depends=('gcc' 'glibc') install="j2re.install"
Rather than these lines,
#source=(http://public.planetmirror.com/pub/java-sun/J2SE/5.0_04/linux32/jre-1_5_0_04... j2re.profile jre.patch) #source=(http://mirror.dcc.fc.up.pt/Java/jre-1_5_0_06-linux-i586.bin j2re.profile jre.patch) [ "$CARCH" == "x86_64" ] && source=(http://mirror.dcc.fc.up.pt/Java/jre-1_5_0_06-linux-amd64.bin j2re.profile jre.patch) md5sums=('e0a88dbec9bfe3195794bb652bfc6516' '87d90b2e075b77c41a7efec7411a4153'\ '3b589fa777fab553d4f7ce57bc90ce48') [ "$CARCH" == "x86_64" ] && md5sums=('6a771c3c9e93021ab34a30bcf609c74b' '87d90b2e075b77c41a7efec7411a4153'\ '91544f3d5d5aa054db7ce2144d17138b')
I would probably do it like this:
source=(j2re.profile jre.patch) md5sums=('87d90b2e075b77c41a7efec7411a4153' '3b589fa777fab553d4f7ce57bc90ce48') [ "$CARCH" = "i686" ] && source=(http://public.planetmirror.com/pub/java-sun/J2SE/5.0_04/linux32/jre-1_5_0_04... ${source[@]}) [ "$CARCH" = "i686" ] && md5sums=('e0a88dbec9bfe3195794bb652bfc6516' ${md5sums[@]}) [ "$CARCH" = "x86_64" ] && source=(http://mirror.dcc.fc.up.pt/Java/jre-1_5_0_06-linux-amd64.bin ${source[@]}) [ "$CARCH" = "x86_64" ] && md5sums=('6a771c3c9e93021ab34a30bcf609c74b' ${md5sums[@]})
And considering below, how you continually repeat jre-1_5_0_06-linux-i586.bin and jre-1_5_0_06-linux-amd64.bin, I would suggest a variable at the top called _binname, set like this:
[ "$CARCH" = "i686" ] && _binname='jre-1_5_0_04-linux-i586.bin' [ "$CARCH" = "x86_64" ] && _binname='jre-1_5_0_06-linux-amd64.bin'
And then every time you have a [ "$CARCH" = "i686" ] && line where the only difference is the filename, replace it like this:
build() { cd $startdir/src [ "$CARCH" == "i686" ] && patch -p0 jre-1_5_0_06-linux-i586.bin <jre.patch [ "$CARCH" == "x86_64" ] && patch -p0 jre-1_5_0_06-linux-amd64.bin <jre.patch
patch -p0 $_binname <jre.patch
mkdir -p $startdir/pkg/opt/java cd $startdir/pkg/opt/java [ "$CARCH" == "i686" ] && echo -e "q\nyes" | sh $startdir/src/jre-1_5_0_06-linux-i586.bin [ "$CARCH" == "x86_64" ] && echo -e "q\nyes" | sh $startdir/src/jre-1_5_0_06-linux-amd64.bin
echo -e "q\nyes" | sh $startdir/src/$_binname
mv jre${pkgver} jre rm -r jre/man/ja* for i in jre/*; do if [ -f $i ]; then rm -f $i; fi done install -D -m755 $startdir/src/${pkgname}.profile $startdir/pkg/etc/profile.d/${pkgname}.sh
# no plugin for x86_64 if [ "$CARCH" == "i686" ]; then mkdir -p $startdir/pkg/opt/mozilla/lib/plugins ln -s /opt/java/jre/plugin/i386/ns7/libjavaplugin_oji.so $startdir/pkg/opt/mozilla/lib/plugins else echo "no plugin for x86_64"
What is this else doing here? The only person who will see that is the builder and I don't know that they would care...
fi }
Something to improve?
AndyRTR
You can also replace the filenames in the new source lines I gave with $_binname, if you wanted to.
How's that for improvement?
Jason
-- If you understand, things are just as they are. If you do not understand, things are just as they are.
_______________________________________________ arch-ports mailing list arch-ports@archlinux.org http://www.archlinux.org/mailman/listinfo/arch-ports
On Sat, Mar 11, 2006 at 05:30:51PM -0500, Dusty Phillips wrote:
These builds are starting to look very un-KISS. Approximately what percentage of PKGBUILDs are going to require architecture-specific code like this? Perhaps it would be better to store multiple versions of the PKGBUILD after all --ie: PKGBUILD-i686 PKGBUILD-x86_64 in the abs directory. This would be a pain when updating duplicate code in each PKGBUILD, but the overall look per PKGBUILD would be far more elegant. It depends how often there is going to be a problem.
No PKGBUILD needs these things. It's only if you want them to support multiple architectures. If we're going to have seperate PKGBUILDs, then we're really just maintaining multiple distros. We might as well just keep Arch i686 and all migrate to Arch64 when i686s become scarce.
Perhaps its just ugly bash syntax and we should think about doing PKGBUILDs in Python. Yeah, I wish too.
I don't know if it'd make them any cleaner. You would need to describe all the same commands and check for architecture changes there too.
Dusty
Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.
participants (7)
-
Andreas Radke
-
Dale Blount
-
Dusty Phillips
-
eliott＠cactuswax.net
-
ganja.guru
-
Jason Chu
-
Maluvia