[arch-general] makepkg creates symlink to the package file
Hello together, since the new pacman a makepkg run creates a symlink to the package file in the directory of the PKGBUILD. Example: # ls -l *.gz opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz -> /server/work/archlinux/repo/opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz My differences to makepkg.conf.pacnew be this: MAKEFLAGS="-j2" CFLAGS="-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer" CXXFLAGS="-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer" BUILDENV=(fakeroot !distcc !color !ccache) OPTIONS=(strip !docs libtool emptydirs zipman purge) PKGDEST=/server/work/archlinux/repo PACKAGER="Attila <SysAdmin@hunnen>" PKGEXT='.pkg.tar.gz' [/server/work is a cifs mount point] Have i overseen something in the makepkg.conf to control this or does no one have this problem ... or is this a new feature which have to be so? See you, Attila
On 23/06/10 07:01, Attila wrote:
Hello together,
since the new pacman a makepkg run creates a symlink to the package file in the directory of the PKGBUILD. Example:
# ls -l *.gz opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz -> /server/work/archlinux/repo/opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz
My differences to makepkg.conf.pacnew be this:
MAKEFLAGS="-j2" CFLAGS="-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer" CXXFLAGS="-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer" BUILDENV=(fakeroot !distcc !color !ccache) OPTIONS=(strip !docs libtool emptydirs zipman purge) PKGDEST=/server/work/archlinux/repo PACKAGER="Attila<SysAdmin@hunnen>" PKGEXT='.pkg.tar.gz'
[/server/work is a cifs mount point]
Have i overseen something in the makepkg.conf to control this or does no one have this problem ... or is this a new feature which have to be so?
New feature. If PKGDEST is set, it creates a symbolic link to the packages in the working directory. I think the idea was that most of the time you will want to "pacman -U <pkg>" at the end of the build and that save you typing the whole PKGDEST path. Allan
On Wed, Jun 23, 2010 at 7:31 AM, Allan McRae <allan@archlinux.org> wrote:
On 23/06/10 07:01, Attila wrote:
Hello together,
since the new pacman a makepkg run creates a symlink to the package file in the directory of the PKGBUILD. Example:
# ls -l *.gz opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz -> /server/work/archlinux/repo/opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz
My differences to makepkg.conf.pacnew be this:
MAKEFLAGS="-j2" CFLAGS="-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer" CXXFLAGS="-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer" BUILDENV=(fakeroot !distcc !color !ccache) OPTIONS=(strip !docs libtool emptydirs zipman purge) PKGDEST=/server/work/archlinux/repo PACKAGER="Attila<SysAdmin@hunnen>" PKGEXT='.pkg.tar.gz'
[/server/work is a cifs mount point]
Have i overseen something in the makepkg.conf to control this or does no one have this problem ... or is this a new feature which have to be so?
New feature. If PKGDEST is set, it creates a symbolic link to the packages in the working directory. I think the idea was that most of the time you will want to "pacman -U <pkg>" at the end of the build and that save you typing the whole PKGDEST path.
Allan
Wouldn't those who want to do that do a makepkg -i? The thing about leaving a symbolic link is that the next time you do pacman -Sc its still there. Scripting removal of dead links is dead simple though, so not a problem for me.
On 23/06/10 10:47, Ng Oon-Ee wrote:
On Wed, Jun 23, 2010 at 7:31 AM, Allan McRae<allan@archlinux.org> wrote:
On 23/06/10 07:01, Attila wrote:
Hello together,
since the new pacman a makepkg run creates a symlink to the package file in the directory of the PKGBUILD. Example:
# ls -l *.gz opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz -> /server/work/archlinux/repo/opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz
My differences to makepkg.conf.pacnew be this:
MAKEFLAGS="-j2" CFLAGS="-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer" CXXFLAGS="-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer" BUILDENV=(fakeroot !distcc !color !ccache) OPTIONS=(strip !docs libtool emptydirs zipman purge) PKGDEST=/server/work/archlinux/repo PACKAGER="Attila<SysAdmin@hunnen>" PKGEXT='.pkg.tar.gz'
[/server/work is a cifs mount point]
Have i overseen something in the makepkg.conf to control this or does no one have this problem ... or is this a new feature which have to be so?
New feature. If PKGDEST is set, it creates a symbolic link to the packages in the working directory. I think the idea was that most of the time you will want to "pacman -U<pkg>" at the end of the build and that save you typing the whole PKGDEST path.
Allan
Wouldn't those who want to do that do a makepkg -i? The thing about leaving a symbolic link is that the next time you do pacman -Sc its still there. Scripting removal of dead links is dead simple though, so not a problem for me.
Possibly... I do not use "makepkg -i" as I use "makepkg -sr" so it removed the makedepends that will be unneeded in the future. Using "makepkg -c" clean up the dangling symlinks. Allan
On Tue, Jun 22, 2010 at 10:48 PM, Allan McRae <allan@archlinux.org> wrote:
On 23/06/10 10:47, Ng Oon-Ee wrote:
On Wed, Jun 23, 2010 at 7:31 AM, Allan McRae<allan@archlinux.org> wrote:
On 23/06/10 07:01, Attila wrote:
Hello together,
since the new pacman a makepkg run creates a symlink to the package file in the directory of the PKGBUILD. Example:
# ls -l *.gz opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz ->
/server/work/archlinux/repo/opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz
My differences to makepkg.conf.pacnew be this:
MAKEFLAGS="-j2" CFLAGS="-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer" CXXFLAGS="-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer" BUILDENV=(fakeroot !distcc !color !ccache) OPTIONS=(strip !docs libtool emptydirs zipman purge) PKGDEST=/server/work/archlinux/repo PACKAGER="Attila<SysAdmin@hunnen>" PKGEXT='.pkg.tar.gz'
[/server/work is a cifs mount point]
Have i overseen something in the makepkg.conf to control this or does no one have this problem ... or is this a new feature which have to be so?
New feature. If PKGDEST is set, it creates a symbolic link to the packages in the working directory. I think the idea was that most of the time you will want to "pacman -U<pkg>" at the end of the build and that save you typing the whole PKGDEST path.
Allan
Wouldn't those who want to do that do a makepkg -i? The thing about leaving a symbolic link is that the next time you do pacman -Sc its still there. Scripting removal of dead links is dead simple though, so not a problem for me.
Possibly... I do not use "makepkg -i" as I use "makepkg -sr" so it removed the makedepends that will be unneeded in the future. Using "makepkg -c" clean up the dangling symlinks.
It is also a very helpful symlink for those of us that like to run namcap after building to check the package. -Dan
At Mittwoch, 23. Juni 2010 06:06 Dan McGee wrote:
It is also a very helpful symlink for those of us that like to run namcap after building to check the package.
That is an advantage ... because i forgot in the most cases to run it and now the motivation to do it is higher.-) See you, Attila
At Mittwoch, 23. Juni 2010 06:06 Dan McGee wrote:
It is also a very helpful symlink for those of us that like to run namcap after building to check the package.
I must correct myself and have a from my view better idea for this. I suggest a new option "-n" (or "--namcap") which runs namacp after a successful build of a package. If "makepkg -cn" is used the symlink gets even deleted (or not created) and in the other cases it can stay at this position. Another question: Is there a way to delete this symlink and his target in one step on the command line? Than this symlink could be a bigger help because you get remembered that there is a older package in your repo. At the end i must say that this symlink is not a problem for me and there be advantages too so i can live with it. So please don't see my points as criticism. See you, Attila
Is there a way to disable the symbolic link creation? I install aur packages using makepkg -ci, but the -ci switch combo does *not* delete the symlink. I don't want them created in the first place, so can I somehow turn off this behavior?
At Mittwoch, 23. Juni 2010 14:20 ProfessorTomoe wrote:
Is there a way to disable the symbolic link creation? I install aur packages using makepkg -ci, but the -ci switch combo does not delete the symlink. I don't want them created in the first place, so can I somehow turn off this behavior?
I start using a shell script for running makepg. At the moment i have no better idea to delete it. But for running namcap right after makepkg this symlink is an advantage. See you, Attila
On Wed, 2010-06-23 at 19:08 +0200, Attila wrote:
Is there a way to disable the symbolic link creation? I install aur packages using makepkg -ci, but the -ci switch combo does not delete the symlink. I don't want them created in the first place, so can I somehow turn off this behavior?
I start using a shell script for running makepg. At the moment i have no better idea to delete it. But for running namcap right after makepkg this symlink is an advantage.
I don't want or need the symlinks to be created in the first place. Can someone advise on how to turn them off? Barring that, could we get a pacman.conf switch to disable symlinks?
On Thu, 24 Jun 2010 07:25:54 -0500 ProfessorTomoe <tomoe@lbjackson.com> wrote:
On Wed, 2010-06-23 at 19:08 +0200, Attila wrote:
Is there a way to disable the symbolic link creation? I install aur packages using makepkg -ci, but the -ci switch combo does not delete the symlink. I don't want them created in the first place, so can I somehow turn off this behavior?
I start using a shell script for running makepg. At the moment i have no better idea to delete it. But for running namcap right after makepkg this symlink is an advantage.
I don't want or need the symlinks to be created in the first place. Can someone advise on how to turn them off?
Barring that, could we get a pacman.conf switch to disable symlinks?
Just _remove_ it: rm -f goddamn-symlink.so What is exactly the problem with it anyway?
At Donnerstag, 24. Juni 2010 14:39 Hilton Medeiros wrote:
Just remove it: rm -f goddamn-symlink.so What is exactly the problem with it anyway?
Your hint is not very productive because you confound cause and effect. The problem is not to delete this file because i think everyone here can use rm. For me this link is now a good help (and memory) to run namcap which i forgot in the most cases and therefore i found my peace with it. But i can understand the wish for a config variable if some don't need this. See you, Attila
On Thu, Jun 24, 2010 at 1:07 PM, Attila <vodoo0904@sonnenkinder.org> wrote:
For me this link is now a good help (and memory) to run namcap which i forgot in the most cases and therefore i found my peace with it. But i can understand the wish for a config variable if some don't need this.
...but that's the whole point of bash/zsh completion. Do you put links to $HOME in /etc or use CDPATH? I mean, modern shells have facilities so let's use them. Joining the list of people that think these links are unnecesary. Andres P
...but that's the whole point of bash/zsh completion. Do you put links to $HOME in /etc or use CDPATH? I mean, modern shells have facilities so let's use
At Donnerstag, 24. Juni 2010 20:06 Andres P wrote: them. You be right and if you look at my other posting my favorite is that pacman can run namcap right after a successfull packaging without the need of a symlink. The extra advantage in this case could be that you have all in one logfile ... but before someone else said it: it is very easy to write your own logfile.
Joining the list of people that think these links are unnecesary.
I'm only not on this list because i found an advantage for me and if this symlink helps the devs than it is okay. And in the case of this aur builder scripts it shouldn't be hard to integrate the deleting of the symlink. Perhaps it could be helpfull that the pacman devs give the information which line is to be comment out in makepkg if you don't wants it and all is fine.-) And here is my very simple suggestion from user to user: LOGFILE="build-$(date --iso-8601).log" /usr/bin/makepkg -c 2>&1 | tee $LOGFILE /usr/bin/namcap *.pkg.tar.xz 2>&1 | tee -a $LOGFILE rm -v *.pkg.tar.xz 2>&1 | tee -a $LOGFILE There is room to optimize it with test statements and so on.-) See you, Attila
On 25 June 2010 01:37, Attila <vodoo0904@sonnenkinder.org> wrote:
At Donnerstag, 24. Juni 2010 14:39 Hilton Medeiros wrote:
Just remove it: rm -f goddamn-symlink.so What is exactly the problem with it anyway?
Your hint is not very productive because you confound cause and effect. The problem is not to delete this file because i think everyone here can use rm.
For me this link is now a good help (and memory) to run namcap which i forgot in the most cases and therefore i found my peace with it. But i can understand the wish for a config variable if some don't need this.
In what kind of situation would someone have something against that symlink? Anyway, you should direct your idea(s) to pacman-dev. -- GPG/PGP ID: B42DDCAD
At Freitag, 25. Juni 2010 08:29 Ray Rashif wrote:
In what kind of situation would someone have something against that symlink?
If you don't ordered it? -) Okay without joking: I think everyone will have something against a thing what he never needs and i'm surprised that no one recognize this very simple answer.
Anyway, you should direct your idea(s) to pacman-dev.
I think it is too late to change it and still again if this helps the devs than it is okay for me. I start only this thread because at first i thought that i have overseen something in the config file. See yoou, Attila
On 26 June 2010 00:59, Attila <vodoo0904@sonnenkinder.org> wrote:
At Freitag, 25. Juni 2010 08:29 Ray Rashif wrote:
In what kind of situation would someone have something against that symlink?
If you don't ordered it? -) Okay without joking: I think everyone will have something against a thing what he never needs and i'm surprised that no one recognize this very simple answer.
For the record, I myself had asked if the symlink could be removed upon cleaning [1], but the purpose this symlink serves is greater than the cleanliness you get from removing it after a build. So, in the end, there should be no other reason to feel that your habits have been violated. [1] http://www.mail-archive.com/pacman-dev@archlinux.org/msg03794.html -- GPG/PGP ID: B42DDCAD
At Samstag, 26. Juni 2010 07:38 Ray Rashif wrote:
[1] http://www.mail-archive.com/pacman-dev@archlinux.org/msg03794.html
Thanks for this information. It seems that at no point it was thought about a config variable and therefore we have to live with it. See you, Attila
On Sat, Jun 26, 2010 at 2:29 AM, Attila <vodoo0904@sonnenkinder.org> wrote:
At Samstag, 26. Juni 2010 07:38 Ray Rashif wrote:
[1] http://www.mail-archive.com/pacman-dev@archlinux.org/msg03794.html
Thanks for this information. It seems that at no point it was thought about a config variable and therefore we have to live with it.
this is all fine and dandy to me. however one little bug: PKGDEST="." makepkg will fail due the the fact that the real package will be overridden by the symlink. result is a circular symbolic link. makepkg should check for this [corner] case, and simply not create the link. i needed this for a script that automatically builds a package with the option to install and/or push to AUR. i wanted to sandbox it so it would not be affected by the user's makepkg.conf settings. workaround by making a dummy folder called "out" and sending the package there instead. C Anthony
On Tue, Jun 29, 2010 at 1:20 PM, C Anthony Risinger <anthony@extof.me> wrote:
On Sat, Jun 26, 2010 at 2:29 AM, Attila <vodoo0904@sonnenkinder.org> wrote:
At Samstag, 26. Juni 2010 07:38 Ray Rashif wrote:
[1] http://www.mail-archive.com/pacman-dev@archlinux.org/msg03794.html
Thanks for this information. It seems that at no point it was thought about a config variable and therefore we have to live with it.
this is all fine and dandy to me. however one little bug:
PKGDEST="." makepkg
will fail due the the fact that the real package will be overridden by the symlink. result is a circular symbolic link. makepkg should check for this [corner] case, and simply not create the link.
i needed this for a script that automatically builds a package with the option to install and/or push to AUR. i wanted to sandbox it so it would not be affected by the user's makepkg.conf settings.
workaround by making a dummy folder called "out" and sending the package there instead.
Wouldn't just setting PKGDEST to nothing instead of "." cover this?
On Tue, Jun 29, 2010 at 12:26 PM, Ray Kohler <ataraxia937@gmail.com> wrote:
On Tue, Jun 29, 2010 at 1:20 PM, C Anthony Risinger <anthony@extof.me> wrote:
On Sat, Jun 26, 2010 at 2:29 AM, Attila <vodoo0904@sonnenkinder.org> wrote:
At Samstag, 26. Juni 2010 07:38 Ray Rashif wrote:
[1] http://www.mail-archive.com/pacman-dev@archlinux.org/msg03794.html
Thanks for this information. It seems that at no point it was thought about a config variable and therefore we have to live with it.
this is all fine and dandy to me. however one little bug:
PKGDEST="." makepkg
will fail due the the fact that the real package will be overridden by the symlink. result is a circular symbolic link. makepkg should check for this [corner] case, and simply not create the link.
i needed this for a script that automatically builds a package with the option to install and/or push to AUR. i wanted to sandbox it so it would not be affected by the user's makepkg.conf settings.
workaround by making a dummy folder called "out" and sending the package there instead.
Wouldn't just setting PKGDEST to nothing instead of "." cover this?
beh, i thought you were onto something... i didn't look at the makepkg sources, but it is treating PKGDEST='"" as if it was never set. so, no dice :-( however, if i use an absolute path (instead of ".") it works alright. in fact, i seem to have general problems with trying to use relative paths as PKGDEST: ==> ERROR: You do not have write permission to store packages in ./pkg/out. Aborting... but i do of course. C Anthony
On 30 June 2010 01:38, C Anthony Risinger <anthony@extof.me> wrote:
On Tue, Jun 29, 2010 at 12:26 PM, Ray Kohler <ataraxia937@gmail.com> wrote:
On Tue, Jun 29, 2010 at 1:20 PM, C Anthony Risinger <anthony@extof.me> wrote:
On Sat, Jun 26, 2010 at 2:29 AM, Attila <vodoo0904@sonnenkinder.org> wrote:
At Samstag, 26. Juni 2010 07:38 Ray Rashif wrote:
[1] http://www.mail-archive.com/pacman-dev@archlinux.org/msg03794.html
Thanks for this information. It seems that at no point it was thought about a config variable and therefore we have to live with it.
this is all fine and dandy to me. however one little bug:
PKGDEST="." makepkg
will fail due the the fact that the real package will be overridden by the symlink. result is a circular symbolic link. makepkg should check for this [corner] case, and simply not create the link.
i needed this for a script that automatically builds a package with the option to install and/or push to AUR. i wanted to sandbox it so it would not be affected by the user's makepkg.conf settings.
workaround by making a dummy folder called "out" and sending the package there instead.
Wouldn't just setting PKGDEST to nothing instead of "." cover this?
beh, i thought you were onto something... i didn't look at the makepkg sources, but it is treating PKGDEST='"" as if it was never set. so, no dice :-(
however, if i use an absolute path (instead of ".") it works alright. in fact, i seem to have general problems with trying to use relative paths as PKGDEST:
==> ERROR: You do not have write permission to store packages in ./pkg/out. Aborting...
but i do of course.
PKGDEST=`pwd` makepkg I do that all the time. -- GPG/PGP ID: B42DDCAD
"C Anthony Risinger" <anthony@extof.me> a écrit :
beh, i thought you were onto something... i didn't look at the makepkg sources, but it is treating PKGDEST='"" as if it was never set. so, no dice :-(
however, if i use an absolute path (instead of ".") it works alright. in fact, i seem to have general problems with trying to use relative paths as PKGDEST:
==> ERROR: You do not have write permission to store packages in ./pkg/out. Aborting...
but i do of course.
Maybe you could use PKGDEST="$(pwd)" as a workaround? -- catwell
On Tue, Jun 29, 2010 at 1:18 PM, Pierre Chapuis <catwell@archlinux.us> wrote:
"C Anthony Risinger" <anthony@extof.me> a écrit :
beh, i thought you were onto something... i didn't look at the makepkg sources, but it is treating PKGDEST='"" as if it was never set. so, no dice :-(
however, if i use an absolute path (instead of ".") it works alright. in fact, i seem to have general problems with trying to use relative paths as PKGDEST:
==> ERROR: You do not have write permission to store packages in ./pkg/out. Aborting...
but i do of course.
Maybe you could use PKGDEST="$(pwd)" as a workaround?
yes this is what i did, thanks. just bringing up the fact that makepkg totally bombs with relative PKGDEST... with a permission error... makepkg must be changing the cwd internally. C Anthony
On 30/06/10 06:08, C Anthony Risinger wrote:
On Tue, Jun 29, 2010 at 1:18 PM, Pierre Chapuis<catwell@archlinux.us> wrote:
"C Anthony Risinger"<anthony@extof.me> a écrit :
beh, i thought you were onto something... i didn't look at the makepkg sources, but it is treating PKGDEST='"" as if it was never set. so, no dice :-(
however, if i use an absolute path (instead of ".") it works alright. in fact, i seem to have general problems with trying to use relative paths as PKGDEST:
==> ERROR: You do not have write permission to store packages in ./pkg/out. Aborting...
but i do of course.
Maybe you could use PKGDEST="$(pwd)" as a workaround?
yes this is what i did, thanks.
just bringing up the fact that makepkg totally bombs with relative PKGDEST... with a permission error... makepkg must be changing the cwd internally.
Use the bug tracker if you want that fixed.
At Mittwoch, 23. Juni 2010 05:48 Allan McRae wrote:
Possibly... I do not use "makepkg -i" as I use "makepkg -sr" so it removed the makedepends that will be unneeded in the future. Using "makepkg -c" clean up the dangling symlinks.
I even use "makepkg -c" too and the symlink is still there. And i never install my own packages with "pacman -U" because i have my own repo on the server. Therefore i use "pacman -S" because than i can install it from my other pc too. Or do you mean that a "makepkg -c" will clean elder invalid symlinks? See you, Attila
On 23/06/10 15:11, Attila wrote:
Or do you mean that a "makepkg -c" will clean elder invalid symlinks?
This one.
On 06/22/10 19:31, Allan McRae wrote:
On 23/06/10 07:01, Attila wrote:
Hello together,
since the new pacman a makepkg run creates a symlink to the package file in the directory of the PKGBUILD. Example:
# ls -l *.gz opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz -> /server/work/archlinux/repo/opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz
My differences to makepkg.conf.pacnew be this:
MAKEFLAGS="-j2" CFLAGS="-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer" CXXFLAGS="-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer" BUILDENV=(fakeroot !distcc !color !ccache) OPTIONS=(strip !docs libtool emptydirs zipman purge) PKGDEST=/server/work/archlinux/repo PACKAGER="Attila<SysAdmin@hunnen>" PKGEXT='.pkg.tar.gz'
[/server/work is a cifs mount point]
Have i overseen something in the makepkg.conf to control this or does no one have this problem ... or is this a new feature which have to be so?
New feature. If PKGDEST is set, it creates a symbolic link to the packages in the working directory. I think the idea was that most of the time you will want to "pacman -U <pkg>" at the end of the build and that save you typing the whole PKGDEST path.
Allan
What about SRCDEST ? Creating a sym link from source package to the build directory would be handy as well.
On 23/06/10 11:55, Baho Utot wrote:
On 06/22/10 19:31, Allan McRae wrote:
On 23/06/10 07:01, Attila wrote:
Hello together,
since the new pacman a makepkg run creates a symlink to the package file in the directory of the PKGBUILD. Example:
# ls -l *.gz opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz -> /server/work/archlinux/repo/opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz
My differences to makepkg.conf.pacnew be this:
MAKEFLAGS="-j2" CFLAGS="-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer" CXXFLAGS="-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer" BUILDENV=(fakeroot !distcc !color !ccache) OPTIONS=(strip !docs libtool emptydirs zipman purge) PKGDEST=/server/work/archlinux/repo PACKAGER="Attila<SysAdmin@hunnen>" PKGEXT='.pkg.tar.gz'
[/server/work is a cifs mount point]
Have i overseen something in the makepkg.conf to control this or does no one have this problem ... or is this a new feature which have to be so?
New feature. If PKGDEST is set, it creates a symbolic link to the packages in the working directory. I think the idea was that most of the time you will want to "pacman -U <pkg>" at the end of the build and that save you typing the whole PKGDEST path.
Allan
What about SRCDEST ? Creating a sym link from source package to the build directory would be handy as well.
Do you mean SRCDEST or SRCPKGDEST. The first should already work, the second has a patch on the pacman mailing list. Allan
participants (12)
-
Allan McRae
-
Andres P
-
Attila
-
Baho Utot
-
C Anthony Risinger
-
Dan McGee
-
Hilton Medeiros
-
Ng Oon-Ee
-
Pierre Chapuis
-
ProfessorTomoe
-
Ray Kohler
-
Ray Rashif