Major fixes for Arch Linux build

Building from Arch Linux binary packages in Woof was broken, very broken.

I added support for Arch Linux back in the "Woof1" days, and Forum member noryb009 added improvements. But it was broken after moving to Woof2, and got more broken later.

I fixed many things, I even hacked on noryb009's awk code in 0setup, despite not having a clue about awk (fixed dependency versioning, removed some bad characters from description fields).

Have now got it to the point of testing "chroot" in 'rootfs-complete' directory, in script '3builddistro' -- and it is failing the chroot.
So, that is the next thing that I need to fix.

Anyway, here is the commit for the changes so far:
http://bkhome.org/fossil/woof2.cgi/info/71441bcc12

---

Comments

Arch pup on ARM
Username: BarryK
Just to let everyone know what is (most likely) going to happen... What motivated me to fix the x86 Arch build in Woof, is I learned that Arch Linux have excellent support for the ARM architecture. They have packages for armv6 and armv7, so I can still build for the RPi while keeping most of my focus on armv7 CPUs. So, once I get the x86 build working, I plan to then fix ARM builds in Woof, and probably do builds for my Mele A1000 and Odroid-X.

Arch: libs moved to /usr/lib
Username: BarryK
"'chroot' was failing, in 3builddistro. I did a quick search, Forum member puppyluvr reported the same error: http://www.murga-linux.com/puppy/viewtopic.php?t=81427 The error is: [i]# chroot rootfs-complete chroot: can't execute '/bin/bash': No such file or directory[/i] Now, there is something very weird that Arch Linux have done, which surprises me, given their philosophy to leave everything as traditional as possible. Or so I thought. They have moved all of the glibc libs out of /lib, to /usr/lib. The big problem with this is that they have [i]always[/i] been in /lib, and it seems that some apps are actually hardcoded to find them there, or so it seems. I fixed the chroot by copying all of the glibc libs back to /lib. Now, I need to put a permanent fix for this into Woof.

Rpi
Username: Sage
"Will your ARM6 be RPi compatible? I ran the Arch .img on Pi but it's CLI-only so well outside my ambit. The Bhodi for ARM- Pi runs extremely well, although the Linux version has come in for some stinging criticism; it certainly is a pain to navigate, which is not the case in Pi. The add-on HW for Pi is amazing, including complete GPIO IF extensions, even Arduino compatible stuff in the CPC catalogue cpc.co.uk.

/usr/*
Username: scsijon
"Mageia 3 has also (partly) moved an awfull lot of 'stuff' across to the /usr directory structure with a plan of moving the rest in Mageia 4. Their idea seems to be that it will speed up execution as well as shrinking the core components. Also, opensuse did it when starting version 12. I wonder how many other distributions have done the same?

Arch: fix glibc
Username: BarryK
"I modified the 'FIXUPHACK' script in the glibc template, to restore glibc to normal layout, with appropriate symlinks in /usr/lib. I fixed execution of post-install scripts in 3builddistro. Still not there, but at least chroot now works. Woof commit: http://bkhome.org/fossil/woof2.cgi/info/d5b7150deb

Query rolling-release model
Username: BarryK
"I am puzzled about the practicality of Arch's rolling-release model, as it pertains to installing individual packages via the package manager. If the repos are constantly changing, doesn't that mean the Puppy Package Manager is going to have to download and update it's local package db every time that the PPM is started? Or at least, every time a package is chosen for installation. Then, installing a package might also mean that some already-installed pkgs will need to be upgraded.

/usr move
Username: mavrothal
"RedHat/Fedora are [url=https://fedoraproject.org/wiki/Features/UsrMove]pushing hard on moving everything to /usr. Besides the stated reasons should be also an issue of compatibility with other *nix cloud platforms (ie solaris) that are moving/moved everything to /usr. Gentoo is also implementing something like this and I guess the others will follow (except debian probably)

/lib symlink to /usr/lib
Username: BarryK
"This explains what Arch have done: http://allanmcrae.com/2012/08/are-we-removing-what-defines-arch-linux/ Ooooh, I don't know if I can change Puppy's filesystem so that /lib is a symlink to /usr/lib.

scary
Username: scsijon
"Barry, your link just above is a little scary if you read through all the comments and sugeations Having /bin, /sbin, /usr/sbin as links all to /usr/bin I'm not sure I agree with to start with, and being required to use systemd would be another major stop I think for puppy. Surely some of the current problems are the absence of directories being listed or added into the correct PATH statements in an applications configuration file, after all there are more than one with libraries having LD_LIBRARY_PATH available. I wonder if it's being afraid to add a config file and have an application actually read it in when starting.

biggest reason for symlinks
Username: technosaurus
"because of things like this strace of bash (you should see gtk apps): [code]open("/lib/tls/i686/sse2/libreadline.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/tls/i686/sse2", 0xbfe1a1b8) = -1 ENOENT (No such file or directory) open("/lib/tls/i686/libreadline.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/tls/i686", 0xbfe1a1b8) = -1 ENOENT (No such file or directory) open("/lib/tls/sse2/libreadline.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/tls/sse2", 0xbfe1a1b8) = -1 ENOENT (No such file or directory) open("/lib/tls/libreadline.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/tls", 0xbfe1a1b8) = -1 ENOENT (No such file or directory) open("/lib/i686/sse2/libreadline.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/i686/sse2", 0xbfe1a1b8) = -1 ENOENT (No such file or directory) open("/lib/i686/libreadline.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/i686", 0xbfe1a1b8) = -1 ENOENT (No such file or directory) open("/lib/sse2/libreadline.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/sse2", 0xbfe1a1b8) = -1 ENOENT (No such file or directory) open("/lib/libreadline.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib", {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0 open("/usr/lib/tls/i686/sse2/libreadline.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/tls/i686/sse2", 0xbfe1a1b8) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/i686/libreadline.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/tls/i686", 0xbfe1a1b8) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/sse2/libreadline.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/tls/sse2", 0xbfe1a1b8) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/libreadline.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/tls", 0xbfe1a1b8) = -1 ENOENT (No such file or directory) open("/usr/lib/i686/sse2/libreadline.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/i686/sse2", 0xbfe1a1b8) = -1 ENOENT (No such file or directory) open("/usr/lib/i686/libreadline.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/i686", 0xbfe1a1b8) = -1 ENOENT (No such file or directory) open("/usr/lib/sse2/libreadline.so.5", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/sse2", 0xbfe1a1b8) = -1 ENOENT ...[/code]

Arch Pup boots to commandline
Username: BarryK
"Arch Pup now boots to the commandline. Still a lot to fix, no X yet. Woof commit: http://bkhome.org/fossil/woof2.cgi/info/e659214779

Tags: woof