Historical bug tracker for the Pacman package manager.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
FS#9342 - makepkg doesn't strip files
Attached to Project:
Pacman
Opened by Jan de Groot (JGC) - Saturday, 26 January 2008, 16:39 GMT
Last edited by Dan McGee (toofishes) - Saturday, 02 February 2008, 16:02 GMT
Opened by Jan de Groot (JGC) - Saturday, 26 January 2008, 16:39 GMT
Last edited by Dan McGee (toofishes) - Saturday, 02 February 2008, 16:02 GMT
|
DetailsFrom the mailinglist:
makegpkg 3.1.1 line ~752 has this... find {,usr/{,local/},opt/}{bin,lib,sbin} -type f and I can't see how that will ever work, and it doesn't for me, however this does work (for me)... find -regex ".+/bin/.+" -o -regex ".+/lib/.+" -o -regex ".+/sbin/.+" -type f I recently rebuilt kdemod4 and it ended up being 1.9Gb whereas it should have been around >400Mb. --markc |
This task depends upon
Closed by Dan McGee (toofishes)
Saturday, 02 February 2008, 16:02 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed in commit c028014f96911930bf3b7dce08c0fe997cedfc69 on maint branch
Saturday, 02 February 2008, 16:02 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed in commit c028014f96911930bf3b7dce08c0fe997cedfc69 on maint branch
Since we're moving away from /opt, this is not as critical as it sounds, but we should keep in mind that our KDE packages are also in /opt.
I think the line Dan suggested there should work :
find {,usr/{,local/},opt/*/}{bin,lib,sbin} -type f
At least, in bash, the following works :
cd /
find opt/*/{bin,sbin} 2>/dev/null
Without the 2>/dev/null, I get the following error though :
find: opt/*: No such file or directory
And that line doesn't work in dash or zsh. But makepkg is an explicit bash script, so that's not a problem, is it?
Doesn't that also mean that we don't have to worry about the portability? Since we use bash find, we should be able
to use the -regex option without problems.
The only issue I could see with the -regex way (find -regex ".+/bin/.+" -o -regex ".+/lib/.+" -o -regex ".+/sbin/.+" -type f)
is that it might match too many things.
Even if regex was supported by say the FreeBSD version of find, this would not work:
find -regex ".+/bin/.+" -o -regex ".+/lib/.+" -o -regex ".+/sbin/.+" -type f
while this would:
find . -regex ".+/bin/.+" -o -regex ".+/lib/.+" -o -regex ".+/sbin/.+" -type f
Finally, output to stderr should not concern us, as long as makepkg suppresses it when the script is run.
freebsd find apparently has -regex, however it explicitly states it is an extension :
http://www.freebsd.org/cgi/man.cgi?query=find&apropos=0&sektion=0&manpath=FreeBSD+6.2-RELEASE&format=html (STANDARDS section)
And openbsd find apparently doesn't have it :
http://www.openbsd.org/cgi-bin/man.cgi?query=find&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html
With all of the above taken into account, I feel like my suggestion of 'opt/*' keeps us good with regards to cross-compatibility, as long as we ensure the error message is not shown. Of course, I think this is a non-issue as the old way had the same error:
$ find opt/{bin,sbin}
find: opt/bin: No such file or directory
find: opt/sbin: No such file or directory
Any objections to my proposed fix?