[arch-dev-public] how to call svn based devtools within a i686 (core) chroot
i keep several chroots alive: core, core/testing, extra, extra/testing. and that twice for each architecture. calling devtools archrelease foo-$CARCH works well for extra and extra/testing also in i686 (linux32) chroots. but how to deal with core chroots? for x86_64 i can run archrelease from outside the chroot. but this won't work for i686. so far i had manually tagged and scp'ed the pkg. how to to this now? moving all subversion related dependencies to core/devel could solve it that are not only a few packages, so it would blow up core a bit too much i think. any idea? btw: how's other devs experience with mkarchroot? is the creation trivial for x86_64 and linux32 i686 chroots? how do you keep the chroot empty or do create each time a new one? is there any advantage beside disc space over permanent chroots? -Andy
On Tue, Apr 8, 2008 at 4:52 PM, Andreas Radke <a.radke@arcor.de> wrote:
i keep several chroots alive: core, core/testing, extra, extra/testing. and that twice for each architecture. calling devtools archrelease foo-$CARCH works well for extra and extra/testing also in i686 (linux32) chroots.
but how to deal with core chroots?
for x86_64 i can run archrelease from outside the chroot. but this won't work for i686. so far i had manually tagged and scp'ed the pkg. how to to this now? moving all subversion related dependencies to core/devel could solve it that are not only a few packages, so it would blow up core a bit too much i think. any idea?
I use the chroot tools whenever I build a package to build the corresponding x86_64 package. There are a few points to this which will answer your question. The most important part is that the chroot tools copy the package OUTSIDE of the chroot when done. There's no reason to have devtools INSIDE the chroot.
btw: how's other devs experience with mkarchroot? is the creation trivial for x86_64 and linux32 i686 chroots? how do you keep the chroot empty or do create each time a new one? is there any advantage beside disc space over permanent chroots?
There is no disc space benefit. The central benefit is that using unionfs allows you to keep a clean chroot no matter what, as the original chroot is mounted in the read-only portion of unionfs. Just delete the RW portion, and it's clean again. On my x86_64 build machine there is only one chroot. All users have a symlink to it, as it is mounted RO, they do not need write access. As you can see from the mail I sent out yesterday, working with i686 chroots is still a little confusing for me, but I am attempting to get there
Andreas Radke schrieb:
for x86_64 i can run archrelease from outside the chroot. but this won't work for i686.
What do you think of this? diff --git a/extrapkg b/extrapkg index d042300..4f94717 100755 --- a/extrapkg +++ b/extrapkg @@ -13,7 +13,17 @@ if [ -r ~/.makepkg.conf ]; then source ~/.makepkg.conf fi -cmd=`basename $0` +cmd=$(basename $0) +case "${cmd}" in + *-*) + cmdarch="$(echo "${cmd}" | cut -d- -f2)" + cmd="$(echo "${cmd}" | cut -d- -f1)" + ;; + *) + cmdarch="" + cmd="${cmd}" + ;; +esac if [ ! -f PKGBUILD ]; then echo "No PKGBUILD file" @@ -21,7 +31,11 @@ if [ ! -f PKGBUILD ]; then fi # define staging areas based on architecture -if [ "$CARCH" = "i686" ]; then +if [ "${cmdarch}" = "i686" ]; then + suffix='' +elif [ "${cmdarch}" = "x86_64" ]; then + suffix='64' +elif [ "$CARCH" = "i686" ]; then suffix='' elif [ "$CARCH" = "x86_64" ]; then suffix='64' We could have symlinks like extrapkg-i686 or extrapkg-x86_64 then.
On Tue, Apr 8, 2008 at 5:34 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Andreas Radke schrieb:
for x86_64 i can run archrelease from outside the chroot. but this won't work for i686.
What do you think of this?
Hmm, I think we might be going a tad crazy with symlinks for that (we just doubled them, and what happens when we get another architecture). Maybe a command line param would be better?
participants (3)
-
Aaron Griffin
-
Andreas Radke
-
Thomas Bächler