[pacman-dev] [PATCH 2/2] Allow wildcards in PURGE_TARGETS to match any type of file except for directories.
From: Jeremy Huntwork
On 29/05/12 02:13, jhuntwork@lightcubesolutions.com wrote:
From: Jeremy Huntwork
Signed-off-by: Jeremy Huntwork
Ack. On my working branch.
--- scripts/makepkg.sh.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index b0918ae..eb239e3 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1048,7 +1048,7 @@ tidy_install() { local pt for pt in "${PURGE_TARGETS[@]}"; do if [[ ${pt} = "${pt//\/}" ]]; then - find . -type f -name "${pt}" -exec rm -f -- '{}' \; + find . ! -type d -name "${pt}" -exec rm -f -- '{}' \; else rm -f ${pt} fi
On Saturday, June 2, 2012 at 9:16 PM, Allan McRae wrote:
scripts/makepkg.sh.in (http://makepkg.sh.in) | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/scripts/makepkg.sh.in (http://makepkg.sh.in) b/scripts/makepkg.sh.in (http://makepkg.sh.in) index b0918ae..eb239e3 100644 --- a/scripts/makepkg.sh.in (http://makepkg.sh.in) +++ b/scripts/makepkg.sh.in (http://makepkg.sh.in) @@ -1048,7 +1048,7 @@ tidy_install() { local pt for pt in "${PURGE_TARGETS[@]}"; do if [[ ${pt} = "${pt//\/}" ]]; then - find . -type f -name "${pt}" -exec rm -f -- '{}' \; + find . ! -type d -name "${pt}" -exec rm -f -- '{}' \; else rm -f ${pt} fi
Sorry for bringing this up after the fact, but with this change is there any reason to execute that if test? Why not just use the find command for all given purge targets? Thanks, JH
On Monday, June 11, 2012 at 9:06 PM, Jeremy Huntwork wrote:
Sorry for bringing this up after the fact, but with this change is there any reason to execute that if test? Why not just use the find command for all given purge targets?
Nevermind - I was thinking of -wholename instead of -name. -wholename is nice, but not usable everywhere. Thanks, JH
On Saturday, June 2, 2012 at 9:16 PM, Allan McRae wrote:
Ack. On my working branch.
--- scripts/makepkg.sh.in (http://makepkg.sh.in) | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/scripts/makepkg.sh.in (http://makepkg.sh.in) b/scripts/makepkg.sh.in (http://makepkg.sh.in) index b0918ae..eb239e3 100644 --- a/scripts/makepkg.sh.in (http://makepkg.sh.in) +++ b/scripts/makepkg.sh.in (http://makepkg.sh.in) @@ -1048,7 +1048,7 @@ tidy_install() { local pt for pt in "${PURGE_TARGETS[@]}"; do if [[ ${pt} = "${pt//\/}" ]]; then - find . -type f -name "${pt}" -exec rm -f -- '{}' \; + find . ! -type d -name "${pt}" -exec rm -f -- '{}' \; else rm -f ${pt} fi
This is what I'm after. Instead of else ; rm -f ${pt}, maybe do: else ; find "${pt%*}" ! -type d -name "${pt##/*}" -exec rm -f -- '{}' + This should allow patterns like dir1/dir2/*.pl, but also match individually specified file names like dir1/dir2/somefile.txt JH
On Monday, June 11, 2012 at 9:26 PM, Jeremy Huntwork wrote:
This is what I'm after. Instead of else ; rm -f ${pt}, maybe do:
else ; find "${pt%*}" ! -type d -name "${pt##/*}" -exec rm -f -- '{}' +
Ugh, typos in my substitutions. should be find "${pt%/*}" ! -type d -name "${pt##*/}" -exec rm -f -- '{}' + That's what I get for sending emails when I'm tired. JH
On 12/06/12 11:48, Jeremy Huntwork wrote:
On Monday, June 11, 2012 at 9:26 PM, Jeremy Huntwork wrote:
This is what I'm after. Instead of else ; rm -f ${pt}, maybe do:
else ; find "${pt%*}" ! -type d -name "${pt##/*}" -exec rm -f -- '{}' +
Ugh, typos in my substitutions. should be
find "${pt%/*}" ! -type d -name "${pt##*/}" -exec rm -f -- '{}' +
That's what I get for sending emails when I'm tired.
Am I missing something here? How does that differ from the plain "rm -f ${pt}"? Allan
On Tuesday, June 12, 2012 at 1:48 AM, Allan McRae wrote:
Am I missing something here? How does that differ from the plain "rm -f ${pt}"?
It matches subdirectories, too, which may or may not be what is really intended. If pattern = "dir1/dir2/*.txt" then: The rm -rf method will match *.txf files in dir1/dir2 The find method will in addition match "dir1/dir2/dir3/*.txt", which may or may not be what is intended. After playing with this for some time, it seems to me that using PURGE_TARGETS only for the contents of a split package is backwards. PURGE_TARGETS may be useful for specifying file patterns (like *.la) that one may not want at all, anywhere (in any package). But I don't think it's useful as describing what should be in the final split package. In situations where you have more than 2 split packages, you'll need to specify certain patterns more than once. Not to mention that there is duplication of effort - 'make install' is run more than once and files are installed and removed from disk more than is necessary. I would much prefer that the package is built with the idea that 'make install' (or equivalent) is done once and that the packaging tool has an overall view of what files are, or are not included in individual packages - such that it can easily keep track of duplicate files added to packages (error: pkg1 has /bin/file1 and so does pkg1-sub1!) or what files were not packaged at all. JH
On Tuesday, June 12, 2012 at 2:09 AM, Jeremy Huntwork wrote:
The rm -rf method will match *.txf files in dir1/dir2
Sorry, that should be rm -f, as it is in the code. JH
On 12/06/12 16:09, Jeremy Huntwork wrote:
On Tuesday, June 12, 2012 at 1:48 AM, Allan McRae wrote:
Am I missing something here? How does that differ from the plain "rm -f ${pt}"?
It matches subdirectories, too, which may or may not be what is really intended.
If pattern = "dir1/dir2/*.txt" then:
The rm -rf method will match *.txf files in dir1/dir2
The find method will in addition match "dir1/dir2/dir3/*.txt", which may or may not be what is intended.
I'd say definitely not what is intended.
After playing with this for some time, it seems to me that using PURGE_TARGETS only for the contents of a split package is backwards. PURGE_TARGETS may be useful for specifying file patterns (like *.la) that one may not want at all, anywhere (in any package). But I don't think it's useful as describing what should be in the final split package. In situations where you have more than 2 split packages, you'll need to specify certain patterns more than once. Not to mention that there is duplication of effort - 'make install' is run more than once and files are installed and removed from disk more than is necessary.
PURGE_TARGETS has absolutely nothing to do with package splitting. It is all about removing files that multiple packages want to include to avoid conflicts, or performing common removals (such as *.la - although we have a specific option just for that).
I would much prefer that the package is built with the idea that 'make install' (or equivalent) is done once and that the packaging tool has an overall view of what files are, or are not included in individual packages - such that it can easily keep track of duplicate files added to packages (error: pkg1 has /bin/file1 and so does pkg1-sub1!) or what files were not packaged at all.
Well then... use rpm. Or more constructively, that is not the design of package splitting in pacman. It was primarily designed for packages that have multiple install targets in their makefiles and so you run "make install-foo" "make install-bar" etc. But saying that, I have had this in my ideas file for quite some time: - Implementing more generic splitting approach for things like the headers splitting: You do a "make install" in the package() function and each package_foo() subpackage function has an array that holds a list of files (including wildcards) to move from the temporary directory into the sub-package. Warnings are printed for any file that is left over. So if you really need that and implement it, I would be amenable to including it. Allan
On Tuesday, June 12, 2012 at 8:15 AM, Allan McRae wrote:
Well then... use rpm. :) Yeah, I have used rpm quite a bit and I do miss some of its functionality. But I also like pacman for being lightweight and fast, with few run-time dependencies (excluding those that makepkg requires). I also like that it manages synchronization with a remote repository itself, instead of requiring another tool or suite of tools in addition (like yum, etc). So even though some of the design of pacman feels unnatural to me after having used rpm, I'm determined to give it a fair chance for the above reasons. Or more constructively, that is not the design of package splitting in pacman. It was primarily designed for packages that have multiple install targets in their makefiles and so you run "make install-foo" "make install-bar" etc.
OK, thanks. I figured that perhaps I was reaching in terms of design intentions.
But saying that, I have had this in my ideas file for quite some time: - Implementing more generic splitting approach for things like the headers splitting: You do a "make install" in the package() function and each package_foo() subpackage function has an array that holds a list of files (including wildcards) to move from the temporary directory into the sub-package. Warnings are printed for any file that is left over.
Yes, something like this would suit me quite well.
So if you really need that and implement it, I would be amenable to including it.
Great! I'll look into it. Thanks, JH
participants (3)
-
Allan McRae
-
Jeremy Huntwork
-
jhuntwork＠lightcubesolutions.com