[pacman-dev] [PATCH] makepkg: fix --allsource when remote source files do not reside in SRCDEST
When using the --allsource option, it was assumed that remote source files reside in SRCDEST which is not necessarily always the case. Signed-off-by: Cedric Staniewski <cedric@gmx.ca> --- scripts/makepkg.sh.in | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 24fddf6..806a325 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1074,9 +1074,10 @@ create_srcpackage() { if [ -f "$netfile" ]; then msg2 "$(gettext "Adding %s...")" "$netfile" ln -s "${startdir}/$netfile" "${srclinks}/${pkgbase}" - elif [ "$SOURCEONLY" -eq 2 -a -f "$SRCDEST/$file" ]; then + elif [ "$SOURCEONLY" -eq 2 ] && [ -f "$file" -o -f "$SRCDEST/$file" ]; then msg2 "$(gettext "Adding %s...")" "$file" - ln -s "$SRCDEST/$file" "${srclinks}/${pkgbase}/" + [ ! -f "$file" ] && file="$SRCDEST/$file" + ln -s "$file" "${srclinks}/${pkgbase}/" fi done -- 1.6.5
On Sat, Oct 17, 2009 at 7:42 PM, Cedric Staniewski <cedric@gmx.ca> wrote:
When using the --allsource option, it was assumed that remote source files reside in SRCDEST which is not necessarily always the case.
I am not familiar with the code, but why aren't all source files in srcdest ? I thought and assumed they were.
Xavier wrote:
On Sat, Oct 17, 2009 at 7:42 PM, Cedric Staniewski <cedric@gmx.ca> wrote:
When using the --allsource option, it was assumed that remote source files reside in SRCDEST which is not necessarily always the case.
I am not familiar with the code, but why aren't all source files in srcdest ? I thought and assumed they were.
If SRCDEST is defined in makepkg.conf, there are actually two possible locations where (remote) source files can be saved to. They can either reside in the configured SRCDEST (which is where makepkg puts downloaded sources) or in the same directory as the PKGBUILD, and moreover, the file in the PKGBUILD directory is favored over the one in SRCDEST. Several functions (check_checksums, extract_sources and probably more) use something like the following to get the correct file name:
if [ ! -f "$file" ] ; then if [ ! -f "$SRCDEST/$file" ] ; then echo "$(gettext "NOT FOUND")" >&2 errors=1 found=0 else file="$SRCDEST/$file" fi fi
This bug can be easily confirmed by running makepkg --allsource in a PKGBUILD directory (obviously the PKGBUILD should use remote sources), extract the generated source package, remove the sources of this package from SRCDEST if defined in makepkg.conf, change into the extracted directory and run makepkg --allsource (-f) again.
On Sat, Oct 17, 2009 at 2:19 PM, Cedric Staniewski <cedric@gmx.ca> wrote:
Xavier wrote:
On Sat, Oct 17, 2009 at 7:42 PM, Cedric Staniewski <cedric@gmx.ca> wrote:
When using the --allsource option, it was assumed that remote source files reside in SRCDEST which is not necessarily always the case.
I am not familiar with the code, but why aren't all source files in srcdest ? I thought and assumed they were.
If SRCDEST is defined in makepkg.conf, there are actually two possible locations where (remote) source files can be saved to. They can either reside in the configured SRCDEST (which is where makepkg puts downloaded sources) or in the same directory as the PKGBUILD, and moreover, the file in the PKGBUILD directory is favored over the one in SRCDEST.
Several functions (check_checksums, extract_sources and probably more) use something like the following to get the correct file name:
if [ ! -f "$file" ] ; then if [ ! -f "$SRCDEST/$file" ] ; then echo "$(gettext "NOT FOUND")" >&2 errors=1 found=0 else file="$SRCDEST/$file" fi fi
This bug can be easily confirmed by running makepkg --allsource in a PKGBUILD directory (obviously the PKGBUILD should use remote sources), extract the generated source package, remove the sources of this package from SRCDEST if defined in makepkg.conf, change into the extracted directory and run makepkg --allsource (-f) again.
So rather than adding more of this code elsewhere, can we maybe factor some of this out into a function? It would also be better to use $startdir/$file to prevent relative path issues from biting us. I'm envisioning some sort of function that takes any item from the source array (url or filename) and returns a absolute file path or something if the file isn't in either of the two places. Does this seem plausible? -Dan
Dan McGee wrote:
On Sat, Oct 17, 2009 at 2:19 PM, Cedric Staniewski <cedric@gmx.ca> wrote:
Xavier wrote:
On Sat, Oct 17, 2009 at 7:42 PM, Cedric Staniewski <cedric@gmx.ca> wrote:
When using the --allsource option, it was assumed that remote source files reside in SRCDEST which is not necessarily always the case.
I am not familiar with the code, but why aren't all source files in srcdest ? I thought and assumed they were.
If SRCDEST is defined in makepkg.conf, there are actually two possible locations where (remote) source files can be saved to. They can either reside in the configured SRCDEST (which is where makepkg puts downloaded sources) or in the same directory as the PKGBUILD, and moreover, the file in the PKGBUILD directory is favored over the one in SRCDEST.
Several functions (check_checksums, extract_sources and probably more) use something like the following to get the correct file name:
if [ ! -f "$file" ] ; then if [ ! -f "$SRCDEST/$file" ] ; then echo "$(gettext "NOT FOUND")" >&2 errors=1 found=0 else file="$SRCDEST/$file" fi fi
This bug can be easily confirmed by running makepkg --allsource in a PKGBUILD directory (obviously the PKGBUILD should use remote sources), extract the generated source package, remove the sources of this package from SRCDEST if defined in makepkg.conf, change into the extracted directory and run makepkg --allsource (-f) again.
So rather than adding more of this code elsewhere, can we maybe factor some of this out into a function? It would also be better to use $startdir/$file to prevent relative path issues from biting us.
I'm envisioning some sort of function that takes any item from the source array (url or filename) and returns a absolute file path or something if the file isn't in either of the two places. Does this seem plausible?
That sounds good to me. It would be worth scanning the code to check there is nowhere else where we could do this too. Allan
Allan McRae wrote:
Dan McGee wrote:
On Sat, Oct 17, 2009 at 2:19 PM, Cedric Staniewski <cedric@gmx.ca> wrote:
Xavier wrote:
On Sat, Oct 17, 2009 at 7:42 PM, Cedric Staniewski <cedric@gmx.ca> wrote:
When using the --allsource option, it was assumed that remote source files reside in SRCDEST which is not necessarily always the case.
I am not familiar with the code, but why aren't all source files in srcdest ? I thought and assumed they were.
If SRCDEST is defined in makepkg.conf, there are actually two possible locations where (remote) source files can be saved to. They can either reside in the configured SRCDEST (which is where makepkg puts downloaded sources) or in the same directory as the PKGBUILD, and moreover, the file in the PKGBUILD directory is favored over the one in SRCDEST.
Several functions (check_checksums, extract_sources and probably more) use something like the following to get the correct file name:
if [ ! -f "$file" ] ; then if [ ! -f "$SRCDEST/$file" ] ; then echo "$(gettext "NOT FOUND")" >&2 errors=1 found=0 else file="$SRCDEST/$file" fi fi
This bug can be easily confirmed by running makepkg --allsource in a PKGBUILD directory (obviously the PKGBUILD should use remote sources), extract the generated source package, remove the sources of this package from SRCDEST if defined in makepkg.conf, change into the extracted directory and run makepkg --allsource (-f) again.
So rather than adding more of this code elsewhere, can we maybe factor some of this out into a function? It would also be better to use $startdir/$file to prevent relative path issues from biting us.
I'm envisioning some sort of function that takes any item from the source array (url or filename) and returns a absolute file path or something if the file isn't in either of the two places. Does this seem plausible?
That sounds good to me. It would be worth scanning the code to check there is nowhere else where we could do this too.
Allan
That definitely sounds good. Will look into that later on this week. Cedric
participants (4)
-
Allan McRae
-
Cedric Staniewski
-
Dan McGee
-
Xavier