- Pacman-dev - lists.archlinux.org

[pacman-dev] Several output issues
by Xavier 28 Sep '07

28 Sep '07

I wonder if the output of this mail won't be a problem in itself, but well I'll give it a try at least. While using pacman 3.1 , I've noticed several issues with the output. Unfortunately I wasn't able to debug any of them, but thought I would share them anyway, in case someone has a clue. I noticed mostly two kinds of issues : 1) Issues with the messages / notifications from src/pacman/callback.c > $ sudo LANG=C pacman -S xf86-video-i810 > resolving dependencies... done. > :: xf86-video-i810 conflicts with xf86-video-intel. Remove xf86-video-intel? [Y/n] looking for inter-conflicts... > done. > > Remove: xf86-video-intel > > Total Removed Size: 0.10 MB > Targets: xf86-video-i810-1.7.4-6 > Total Package Size: 3.55 MB > Total Installed Size: 9.87 MB > Proceed with installation? [Y/n] That "looking for inter-conflicts..." message looks a bit weird there. > $ sudo LANG=C pacman -S xterm > :: xterm-229-2: local version is up to date. Upgrade anyway? [Y/n] > resolving dependencies... done. > looking for inter-conflicts... done. > > Targets: xterm-229-2 > > Total Package Size: 0.20 MB > > Proceed with installation? [Y/n] > :: Archive xterm-229-2.pkg.tar.gz is corrupted. Do you want to delete it? [Y/n] checking package integrity... > error: failed to commit transaction (corrupted package) > archive xterm-229-2.pkg.tar.gz was corrupted (bad MD5 checksum) > Errors occurred, no packages were upgraded. Same for "checking package integrity..." here. 2) Issues with the progress bar (used in remove_commit and commit_single_pkg) > $ sudo LANG=C pacman -R xorg-xinit xorg-twm > loading package data... checking dependencies... done. > warning: /etc/X11/twm/system.twmrc saved as /etc/X11/twm/system.twmrc.pacsave > (1/2) removing xorg-twm [############################] 100% > warning: /etc/skel/.xinitrc saved as /etc/skel/.xinitrc.pacsave------------------] 0% > (2/2) removing xorg-xinit [############################] 100 > $ sudo LANG=C pacman -S xorg-xinit xorg-twm > :: xorg-xinit-1.0.5-1: local version is up to date. Upgrade anyway? [Y/n] > :: xorg-twm-1.0.1-2: local version is up to date. Upgrade anyway? [Y/n] > resolving dependencies... done. > looking for inter-conflicts... done. > > Targets: xorg-xinit-1.0.5-1 xorg-twm-1.0.1-2 > > Total Package Size: 0.10 MB > > Proceed with installation? [Y/n] > checking package integrity... done. > (2/2) checking for file conflicts [############################] 100% > (1/2) upgrading xorg-xinit [############################] 100% > warning: /etc/X11/twm/system.twmrc installed as /etc/X11/twm/system.twmrc.pacnew-] 0% > (2/2) upgrading xorg-twm [############################] 100 > $ sudo LANG=C pacman -S filesystem > :: filesystem-2007.08-2: local version is up to date. Upgrade anyway? [Y/n] > resolving dependencies... done. > looking for inter-conflicts... done. > > Targets: filesystem-2007.08-2 > > Total Package Size: 0.10 MB > > Proceed with installation? [Y/n] > checking package integrity... done. > (1/1) checking for file conflicts [############################] 100% > warning: directory permissions differ on proc/ [----------------------------] 0% > filesystem: 555 package: 755(1/1) upgrading filesystem [############################] 100% That last one is a bit particular, I think it was missed during that last newline commit : http://projects.archlinux.org/git/?p=pacman.git;a=commit;h=5c9eec5570c145c0… But after adding newlines, it just behaves like the above ones, the messages end with a progressbar, and it looks rather odd. I think I see at least 2 workarounds for this problem : * totally disable all these warnings during extraction * buffer the messages, and display them only after all the files have been extracted. There might be a better solution that doesn't require any of these though. Wouldn't it be possible to just clear the line before outputting the messages, or something like that, and let the progress bar redisplay itself on the next line?

2 8

[pacman-dev] [GIT] pacman branch, master now at v3.0.0-419-g012f793
by Dan McGee 28 Sep '07

28 Sep '07

Hello, This is an automated email from the git hooks/update script, it was generated because a ref change was pushed to the repository. Updating branch, master, via 012f7939784358b02726c169543aa99436439335 (commit) via 843d368ef60a74719dfc74a27de3fe3ef441951f (commit) via 105fd40a4a9b221df0186e7500fe491b3b96d823 (commit) via 6898bb0f9742e078f2c45609cf00d43438a14843 (commit) via 8acb6d24af81d57ed87339aaf3472bda28b3a38d (commit) via d3c80030201b555efba2f31811cff627a3fdeaf8 (commit) via 443950b7e9c40493a184d55caaa71c2b4daa3ffd (commit) via f9b7c67d24210dc4b2c77b751948e0f17f80583f (commit) via 1860ab898086096ef0d9aad66e29f86cbf271423 (commit) from 7325ebbc22091c698fd19140b7ed6986024ec6e8 (commit) - Log ----------------------------------------------------------------- commit 012f7939784358b02726c169543aa99436439335 Author: Dan McGee <dan(a)archlinux.org> Date: Sun Sep 23 21:19:06 2007 -0500 Allow a normal 'make' to compile without asciidoc installed If we don't have asciidoc installed or enabled, we should still have a successful make. However, we want to ensure 'make dist' fails without asciidoc. This commit should ensure this. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 843d368ef60a74719dfc74a27de3fe3ef441951f Author: Dan McGee <dan(a)archlinux.org> Date: Sun Sep 23 14:43:03 2007 -0500 libalpm/add.c: fix backup array issue As seen with the recent upgrade of pacman and the removal of the pacman.d/current mirrorlist, files that were formerly in the backup array get deleted upon their removal, which could be dangerous. Instead, we should use the combined backup array of the old and new package. This fix should address this issue in a relatively straightforward way. In addition, old files should be moved to pacsave locations as expected. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 105fd40a4a9b221df0186e7500fe491b3b96d823 Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Sun Sep 23 17:07:13 2007 +0200 Add sync044 pactest : A dependency induces a replacement. That is the problem mentioned by Nagy there (with suggestions for fixing it) : http://www.archlinux.org/pipermail/pacman-dev/2007-August/009082.html If a dependency conflicts with a local package and has to replace it, the PM_SYNC_TYPE_DEPEND information is lost, and the resulting install reason is wrong (the package is marked as explictly installed). Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> commit 6898bb0f9742e078f2c45609cf00d43438a14843 Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Sun Sep 23 16:53:05 2007 +0200 Add two pactests with broken requiredby, and two about pacsave handling. remove048 is the case mentioned there (fails in 3.0 but works in 3.1) : http://www.archlinux.org/pipermail/pacman-dev/2007-September/009294.html It's the same as remove046 with -R instead of -Rc. sync060 is a case reported this morning on IRC : a pacman -Su wanted to replace gensplashutils by gensplash, but pacman said gensplashutils was required by initscripts-gensplash, while initscripts-gensplash was not even installed. This is also fixed in the current 3.1 code though. upgrade02{4,5} are the backup handling problem I described there : http://www.archlinux.org/pipermail/pacman-dev/2007-September/009376.html Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> commit 8acb6d24af81d57ed87339aaf3472bda28b3a38d Author: Dan McGee <dan(a)archlinux.org> Date: Sun Sep 23 15:44:40 2007 -0500 libalpm/remove.c: fix up arguments to unlink_file Move the progressbar code out of unlink_file so we can pass half the args. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit d3c80030201b555efba2f31811cff627a3fdeaf8 Author: Dan McGee <dan(a)archlinux.org> Date: Sun Sep 23 12:20:48 2007 -0500 alpm: removed unused strtoupper wrapper, remove installeddate on parse_descfile installdate should never be present in a package descfile, so get rid of it. With the last commit, we also don't need the util strtoupper function. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 443950b7e9c40493a184d55caaa71c2b4daa3ffd Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Sun Sep 23 19:01:37 2007 +0200 libalpm/package.c : fix for FS#8081, case sensitive comparisons in parse_descfile. This fix FS#8081. The tr_TR locale has known issue with case insensitive comparisons, mostly because upper(i) != I. So the .PKGINFO files generated by makepkg MUST contain all keywords in lowercases now. This was already done, but was not mandatory. Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> commit f9b7c67d24210dc4b2c77b751948e0f17f80583f Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Tue Sep 18 20:46:41 2007 +0200 libalpm/add.c : fix backup handling (2) The mistake fixed in commit 26441cf65ca10d4bf218203df5db5e8a7270787b was actually done at two places. This fix the second one. Also remove one unnecessary newline introduced by commit d34b2c4ed84bc40f4a895846785481fad88116a2 Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> commit 1860ab898086096ef0d9aad66e29f86cbf271423 Author: Dan McGee <dan(a)archlinux.org> Date: Tue Sep 18 13:40:19 2007 -0500 Update NEWS, -S testing/qt example, and mirrorlist change Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Diffstat: NEWS | 14 ++++-- doc/Makefile.am | 9 ++++ doc/pacman.8.txt | 2 +- etc/pacman.d/mirrorlist.in | 2 +- lib/libalpm/add.c | 22 ++++++--- lib/libalpm/package.c | 33 ++++++------- lib/libalpm/remove.c | 62 +++++++++++------------- lib/libalpm/util.c | 13 ----- lib/libalpm/util.h | 1 - pactest/tests/remove048.py | 10 ++++ pactest/tests/sync044.py | 20 ++++++++ pactest/tests/sync060.py | 15 ++++++ pactest/tests/upgrade010.py | 1 + pactest/tests/upgrade020.py | 1 + pactest/tests/upgrade021.py | 1 + pactest/tests/upgrade022.py | 1 + pactest/tests/upgrade023.py | 1 + pactest/tests/upgrade024.py | 15 ++++++ pactest/tests/{upgrade021.py => upgrade025.py} | 6 +- 19 files changed, 146 insertions(+), 83 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ 7325ebbc22091c698fd19140b7ed6986024ec6e8 \ 012f7939784358b02726c169543aa99436439335

3 5

[pacman-dev] [GIT] pacman branch, master now at v3.0.0-427-g2198087
by Dan McGee 28 Sep '07

28 Sep '07

Hello, This is an automated email from the git hooks/update script, it was generated because a ref change was pushed to the repository. Updating branch, master, via 219808714f94788a66a430786c552f60e95b1a01 (commit) via d2edcb58e2252f90447694acc7736c0ba5b1f01e (commit) via 16cb8e6e61c542731814192fc03e3988c7a26325 (commit) via f7bbfe4052ca1060d2d1021dacd77923d8ab6786 (commit) via 0758012b6617fd25f3af84853611b9adaf65f674 (commit) via 679eff90cc94593ff24f1927c40843865252c3ca (commit) via a6b58638d12300d826e47697aa7bdc012b7f6684 (commit) via fc0e83f05b29f57accb49544dabe856968349b3a (commit) from 012f7939784358b02726c169543aa99436439335 (commit) - Log ----------------------------------------------------------------- commit 219808714f94788a66a430786c552f60e95b1a01 Author: Dan McGee <dan(a)archlinux.org> Date: Thu Sep 27 23:39:37 2007 -0500 Add 'full' parameter to alpm_pkg_load In most cases, we want to fully scan a package when we load it, which serves as a integrity verification check. However, there are times when it is only desired to read the metadata and nothing else, so allow the caller of pkg_load to choose the behavior they need. This pays big dividends in speeding up pacman cache cleaning functionality. Old (729 packages): real 1m43.717s user 1m20.785s sys 0m2.993s New (729 packages): real 0m25.607s user 0m19.389s sys 0m0.543s Signed-off-by: Dan McGee <dan(a)archlinux.org> commit d2edcb58e2252f90447694acc7736c0ba5b1f01e Author: Dan McGee <dan(a)archlinux.org> Date: Thu Sep 27 22:47:25 2007 -0500 Update comments dealing with pkgext/dbext stripping pacman/callback.c already did the work I set out to do with this commit, so update the comments accordingly in the frontend and backend. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 16cb8e6e61c542731814192fc03e3988c7a26325 Author: Dan McGee <dan(a)archlinux.org> Date: Tue Sep 25 22:07:36 2007 -0500 Reimplement pacman cache cleaning the right way Partial cache cleaning was eliminated in a previous commit because it relied on package naming conventions. Re-add it the correct way- we actually open up each package in the cache and get a name and version out of it. If the name and version match that of an installed package, keep it. If the package is not installed or the version does not match the locally-installed version, get rid of it. This can easily be modified if some other heuristic of keeping and removing packages is desired, or if we should clean out the cache dir of any files that are not packages, etc. The biggest current problem with this new approach- speed. Here is one run on my local machine, going from 1643 to 729 packages in the cache (753 in the local DB): real 4m25.829s user 3m22.527s sys 0m6.713s This is likely best addressed by the package loading scheme, which may be loading the entirety of each package archive, which is a waste when we only need the .PKGINFO file read. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit f7bbfe4052ca1060d2d1021dacd77923d8ab6786 Author: Dan McGee <dan(a)archlinux.org> Date: Sun Jun 17 23:25:07 2007 -0400 Remove package name dependency from libalpm Previously, package names must match a specified scheme or they will cause pacman add operations to fail. This is not a very intelligent or necessary way to act, so remove the dependency on the name of the package to be installed and read all relevant information from the metadata instead. This does have one causality to be addressed later- pacman cache cleaning functionality, which has never been phenomenal, just lost most capability. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 0758012b6617fd25f3af84853611b9adaf65f674 Author: Dan McGee <dan(a)archlinux.org> Date: Fri Sep 28 00:15:10 2007 -0500 libalpm: Add newline to alpm log function output Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 679eff90cc94593ff24f1927c40843865252c3ca Author: Dan McGee <dan(a)archlinux.org> Date: Thu Sep 27 22:13:33 2007 -0500 Mirrorlist updates Signed-off-by: Dan McGee <dan(a)archlinux.org> commit a6b58638d12300d826e47697aa7bdc012b7f6684 Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Wed Sep 26 18:59:40 2007 +0200 document the -Qii option. I suppose -Qii could be used for other things than displaying the list of backup files, but currently, it's the only one, so that's how I documented it.. Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit fc0e83f05b29f57accb49544dabe856968349b3a Author: Dan McGee <dan(a)archlinux.org> Date: Tue Sep 25 23:02:30 2007 -0500 Preliminary support for optdepends Add some alpm functions for getting optdepends, have makepkg include them in the PKGINFO file, and have a pacman -Qi operation display the raw string as stored by libalpm. Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Diffstat: doc/pacman.8.txt | 4 +- etc/pacman.d/mirrorlist.in | 14 ++--- lib/libalpm/add.c | 47 +++---------- lib/libalpm/alpm.h | 12 +--- lib/libalpm/be_files.c | 54 ++++++++++++++- lib/libalpm/log.h | 2 +- lib/libalpm/package.c | 160 +++++++++++++------------------------------- lib/libalpm/package.h | 4 +- lib/libalpm/server.c | 12 +--- scripts/makepkg.sh.in | 5 +- src/pacman/callback.c | 3 +- src/pacman/package.c | 1 + src/pacman/pacman.c | 2 +- src/pacman/query.c | 2 +- src/pacman/sync.c | 134 +++++++++++-------------------------- src/util/testpkg.c | 2 +- 16 files changed, 170 insertions(+), 288 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ 012f7939784358b02726c169543aa99436439335 \ 219808714f94788a66a430786c552f60e95b1a01

2 1

[pacman-dev] [GIT] pacman branch, master now at v3.0.0-435-g69d68ef
by Dan McGee 28 Sep '07

28 Sep '07

Hello, This is an automated email from the git hooks/update script, it was generated because a ref change was pushed to the repository. Updating branch, master, via 69d68ef0b5804435bdf19d15e139f644639caa7b (commit) from 48bf088e65403049dc430fadf360355a8d5dc07d (commit) - Log ----------------------------------------------------------------- commit 69d68ef0b5804435bdf19d15e139f644639caa7b Author: Dan McGee <dan(a)archlinux.org> Date: Fri Sep 28 00:36:48 2007 -0500 makepkg: When we add an option, we should probably make it work The -A,--ignorearch option was added and given help text, but never actually listed as valid to the option parser. Fix this. Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Diffstat: scripts/makepkg.sh.in | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ 48bf088e65403049dc430fadf360355a8d5dc07d \ 69d68ef0b5804435bdf19d15e139f644639caa7b

1 0

[pacman-dev] package loading scheme
by Xavier 27 Sep '07

27 Sep '07

Last commit on Dan's pkgname_check branch : http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=commitdiff;h=b3d5764134… > Partial cache cleaning was eliminated in a previous commit because it relied > on package naming conventions. Re-add it the correct way- we actually open > up each package in the cache and get a name and version out of it. If the > name and version match that of an installed package, keep it. If the package > is not installed or the version does not match the locally-installed version, > get rid of it. > > This can easily be modified if some other heuristic of keeping and removing > packages is desired, or if we should clean out the cache dir of any files > that are not packages, etc. > > The biggest current problem with this new approach- speed. Here is one run > on my local machine, going from 1643 to 729 packages in the cache (753 in > the local DB): > real 4m25.829s > user 3m22.527s > sys 0m6.713s > > This is likely best addressed by the package loading scheme, which may be > loading the entirety of each package archive, which is a waste when we only > need the .PKGINFO file read. That's a difference with frugalware I noticed earlier : http://www.archlinux.org/pipermail/pacman-dev/2007-June/008524.html Back then, I thought fw added this feature. But actually, it's the other way around, this feature was removed in arch, in this commit : http://projects.archlinux.org/git/?p=pacman.git;a=commit;h=b2da4b42344444dc… And this was caused by this bug report : http://bugs.archlinux.org/task/5120 I actually have to ask the same as Aaron in one of his comment there : "Ok, after re-looking at this, I'm fairly confused. If a gzip file is corrupt, shouldn't the gunzipping algorithm/whatever KNOW that? How does it even begin to extract itself, if it's corrupt? I don't know compression algorithms that well, but I thought there was some sort of check for this?" I just started downloading a package with wget, cancelled it, then tried to install it with pacman, and : loading package data... error: error while reading package: Premature end of gzip compressed data: Input/output error I restored the old code that prevented reading the whole archive : 956 if(config && filelist && scriptcheck) { 957 /* we have everything we need */ 958 break; 959 } And after that, I got : loading package data... error: error while reading package: (Empty error message) So apparently, it still fails, which is good. However, it apparently doesn't fail at the same point, because of this Empty error message. So I didn't figure out yet where it failed exactly, and if it'll fail with all corrupted archives. At least, it doesn't work with any corrupted archives, which might be good enough for restoring that feature. The times showed by Dan are quite crazy :)

3 3

[pacman-dev] makepkg colors with a dark on light terminal
by Xavier 27 Sep '07

27 Sep '07

While trying some light colorscheme, using a dark on white xterm (which is also the default), I noticed that most makepkg output was invisible. For example, just running makepkg in a directory without PKGBUILD display this message : ==> ERROR: PKGBUILD does not exist. The "PKGBUILD does not exist" part is always displayed in white, both with dark and light backgrounds. I checked with makepkg 3.0, and it works fine in both cases. That is, it uses the foreground color for displaying normal text.

2 2

[pacman-dev] document the -Qii option.
by Chantry Xavier 26 Sep '07

26 Sep '07

I suppose -Qii could be used for other things than displaying the list of backup files, but currently, it's the only one, so that's how I documented it.. Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> --- doc/pacman.8.txt | 4 +++- src/pacman/pacman.c | 2 +- 2 files changed, 4 insertions(+), 2 deletions(-)

1 0

[pacman-dev] support of optional dependencies
by Pierre Schmitz 25 Sep '07

25 Sep '07

Hi, while working on php I realized that I really need something like "optionaldepends" in a PKGBUILD. I am not sure about the current status of this; the last time it was decided that we print some message to the user using the install scripts. But I am not very happy with that kind of workaround. It would be much cleaner to have such support in makepkg/pacman itself. It would be enough if those are just information which the user can ask for if needed. Currently you have to grep through pacman.log to see those messages after you have installed a package. It could be implemented the following way: PKGBUILD optionaldepends=('package':'optional description why you might want to \ isntall this optional package' \ 'next package') makepkg treat optionaldepends like makedepends pacman show optional packages and their (optional) description after install add a switch to show those information after the package is allready installed As an example of how "userfriendly" our current solution is see <http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/devel/php/php.install?rev=1.5&…> Pierre -- archlinux.de

7 11

[pacman-dev] backup handling
by Xavier 24 Sep '07

24 Sep '07

stonecrest noticed during last pacman upgrade that the /etc/pacman.d/current file was removed, although that file was in the backup array of previous packages, and might have been modified by the user. pacman 3.0.5-3 contained only /etc/pacman.d/current file and had it in its backup array. pacman 3.0.5-4 contained only /etc/pacman.d/core file and had it in its backup array. And on 3.0.5-3 -> 3.0.5-4 upgrade, the current file is removed, without any backup. While in this case, it was totally harmless, in the general case, it might not be the desired behavior. As we know, in pacman, an upgrade is a remove + add progress. The remove is a special one though, since we dont want to lose the config files. So pacman adds all files in the backup array to NoUpgrade, so that these files are not removed. But it picks only the files of the new backup array, as seen there : 298 /* Add files in the NEW package's backup array to the noupgrade array 299 * so this removal operation doesn't kill them */ 300 /* TODO if we add here, all backup=() entries for all targets, new and 301 * old, we cover all bases, including backup=() locations changing hands. 302 * But is this viable? */ So during 3.0.5-3 -> 3.0.5-4 , the current file was not added to noupgrade and was then lost. Implementing the above TODO would probably fix the issue, and it should be pretty easy to do. But I'm a bit concerned by the last comment : "But is this viable?" What are really the downsides of doing this? While writing this, I may seen one inconvenient, it's that it might not be obvious to the user that this current file is no longer used and owned by pacman. Maybe it should be renamed to current.pacsave then ?

4 10

[pacman-dev] Pacman for LFS
by Walter Barnes 24 Sep '07

24 Sep '07

Hello, I understand that this is a developers list but I have a users question, if this is not the correct list to post to please let me know where I should post, thanks. My question involves adapting pacman to a LFS system. After going through the man pages, it seems that to separate pacman from Arch Linux all I need to do is modify pacman.conf to point to my own local repository and remove all pre-configured repository sections. Is this correct or is there another step I need to do as well? Also, when running configure with --prefix=/tools I found that all config files end up in /tools/etc but it seems that pacman and makepkg still look for the config files in /etc. I did some digging and found the --with-config-file option for pacman.conf but there is no equivelant for makepkg.conf and ended up editing the script by hand. I'm new to Linux and know nothing about automake/autoconf build systems but would it be possible to have configure generate the makepkg script with the correct location of makepkg.conf (and abs.conf too)? Thanks, Walter ____________________________________________________________________________________ Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC

3 2