On Wed, Jun 23, 2010 at 7:31 AM, 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" 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 Tue, Jun 22, 2010 at 10:48 PM, Allan McRae wrote:

On 23/06/10 10:47, Ng Oon-Ee wrote:

...

On Wed, Jun 23, 2010 at 7:31 AM, 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" 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.

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

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 Thu, 24 Jun 2010 07:25:54 -0500 ProfessorTomoe 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?

On Thu, Jun 24, 2010 at 1:07 PM, Attila 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

On 25 June 2010 01:37, Attila 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

On 26 June 2010 00:59, Attila 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

On Sat, Jun 26, 2010 at 2:29 AM, Attila 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 12:26 PM, Ray Kohler wrote:

On Tue, Jun 29, 2010 at 1:20 PM, C Anthony Risinger wrote:

...

On Sat, Jun 26, 2010 at 2:29 AM, Attila 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

"C Anthony Risinger" 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 30/06/10 06:08, C Anthony Risinger wrote:

On Tue, Jun 29, 2010 at 1:18 PM, Pierre Chapuis wrote:

...

"C Anthony Risinger" 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.

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" 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.