Shingoshi, in most cases it'd be fine, but there are legitimate uses of lib in a 64 bit system. Like, for instance, building 32-bit userspace apps/libs. The toolchain in slamd64 is biarch, but the arch will always get detected as x86_64, so the libs (you might conceivable want to have the same libs in both lib and lib64 to link against) will be forced into the wrong place, and might even overwrite original ones ...
Having the check you suggested in src2pkg verbatim makes it difficult at best to work around when you really need to, hence the poorly explained objection. What's likely the source of your particular problem is poorly written makefiles with absolute paths and/or no honoring of the --prefix in an autotools package. Having a correctly set up pkgconfig path will put all those .pc files in the correct and sensible place. I'd be interested in taking a look at the sources which cause you problems in this way; forgive me if you've already sorted this, and let's move on to some fun stuff!
Been having a think on the repository issue. Best i've come up with is this sample code:
Code:
#!/bin/bash
# Pilfered from src2pkg
# ANSI COLORS
CRE="[K"
NORMAL="[0;39m"
# RED: Failure or error message
RED="[1;31m"
# GREEN: Success message
GREEN="[1;32m"
# YELLOW: Warnings
YELLOW="[1;33m"
# BLUE: Summary messages
BLUE="[1;34m"
# CYAN: Current Process
CYAN="[1;36m"
# These are obtained from the package you're trying to build.
program[0]="amsn"
program[1]="amarok"
program[2]="glibc"
program[3]="imlib2"
program[4]="imlib2-1.2.1"
# These either need mapping 1:1 with the package name, or just listing and then looping through, probably per repository. For the sake of simplicity, i'm going direct to the source.
category[0]="network"
category[1]="kde"
category[2]="l"
category[3]="Libs"
# These are stored locally
# slackbuilds
repository[0]="www.slackbuilds.org"
lpath[0]="slackbuilds/12.0"
suffix[0]=".tar.gz"
repath[0]="/${lpath[0]}/${category[0]}/${program[0]}${suffix[0]}"
# Part of the crux repository
repository[1]="crux.nu"
lpath[1]="ports/crux-2.4"
suffix[1]="Pkgfile"
repath[1]="/${lpath[1]}/${category[1]}/${program[1]}/${suffix[1]}"
# Slackware SlackBuild repository
repository[2]="ftp.heanet.ie"
lpath[2]="mirrors/ftp.slackware.com/pub/slackware/slackware-current/source"
suffix[2]="SlackBuild"
repath[2]="/${lpath[2]}/${category[2]}/${program[2]}/${program[2]}.${suffix[2]}"
# For Gilbert's repository we run into difficulties, because he keeps track of version numbers:
# http://distro.ibiblio.org/pub/linux/distributions/amigolinux/download/Libs/imlib2-1.2.1/
repository[3]="distro.ibiblio.org"
lpath[3]="pub/linux/distributions/amigolinux/download"
suffix[3]="PkgBuild"
repath[3]="/${lpath[3]}/${category[3]}/${program[3]}/${program[3]}.${suffix[3]}"
# Replicating this repo, but adding in the version number should work, and the version number may be extracted from the source tarball at your finger tips anyway.
repository[4]="distro.ibiblio.org"
repath[4]="/${lpath[3]}/${category[3]}/${program[4]}/${program[3]}.${suffix[3]}"
# Count the number of repositories for this test
x=${#repository[@]}
for ((i=0;i<$x; i+=1)); do
echo ${repath[$i]}
(echo -e "HEAD ${repath[$i]} HTTP/1.0\r\n\r\n" 1>&3 & cat 0<&3) 3<> /dev/tcp/${repository[$i]}/80
tmp=`(echo -e "HEAD ${repath[$i]} HTTP/1.0\r\n\r\n" 1>&3 & cat 0<&3) 3<> /dev/tcp/${repository[$i]}/80 | grep "200 OK" | wc -l`
if [ $tmp == 1 ]; then
echo "${BLUE}${program[$i]} - ${GREEN}found."
else
echo "${BLUE}${program[$i]} - ${RED}not found!!"
fi
echo ${NORMAL}
done
You'll see basically it queries the repositories to see if a script exists on that repository. Some information still has to be retained locally, such as the repository itself, the repository's format and likely some sort of category list per repository.
I've used arrays for everything, but it can be recoded to store all the information in 3 1D arrays: repository, repath and category. The sample is also a bit inelegant considering i'm only checking for HTTP responses of "200 OK", and like in the case of Amigo, this fails a bit since it's been permanently moved (301). More rigorous checking needed for that to really work. Likewise i'm also spamming the servers twice in the for-loop so you can see the output - obviously this is bad news from a bandwidth point of view.
The other problem with this approach is that it makes no attempt to "look" into the directory where the thing it's downloading is located - for example the slackware source repo has a lot of patches, and some places keep the slack-desc files separate too.
I can see possibilities of adding a cache into this, too, so once you've located the source, you can just pull it again easily. If the cache is one file (or one directory), mirroring it across multiple PCs would be easily done, too.
In the end, I suppose, it depends how many repos you end up adding to the script!
Either way, hope this gives some inspiration. I borrowed the initial HTTP code from
http://www.pebble.org.uk/linux/bashbrowser and adapted it so it didn't get the whole page.
Take care,
- Piete.
