Package Details: berusky2-data 0.12-3

Git Clone URL: (read-only, click to copy)
Package Base: berusky2-data
Description: A logic game based on the puzzle game Sokoban (Data files).
Upstream URL:
Licenses: GPL
Submitter: ilpianista
Maintainer: SanskritFritz
Last Packager: SanskritFritz
Votes: 5
Popularity: 0.000000
First Submitted: 2011-07-15 08:42 (UTC)
Last Updated: 2020-11-30 21:01 (UTC)

Dependencies (0)

Required by (1)

Sources (1)

Latest Comments

1 2 3 Next › Last »

SanskritFritz commented on 2020-12-02 14:43 (UTC)

Thanks for the compliment!

ccorn commented on 2020-12-02 14:14 (UTC)

Would you like to be co-maintainer?

No, thanks. I am fine with the current state.

SanskritFritz commented on 2020-12-02 11:46 (UTC)

Fair point! OK, I'll leave it like this. Would you like to be co-maintainer?

ccorn commented on 2020-12-01 14:30 (UTC)

I think I'll just simply merge the the data into the berusky2 package. What do you think?

Better keep them separate. The actual program (berusky2) may need to be rebuilt and reinstalled if some dependency (e.g. SDL or GLU) changes. If there is a large separate data package (as is the case here, with size larger than 500 MB), that amount of data does not need to be repackaged and reinstalled again. Thus rebuilds and reinstalls are significantly smaller, which is good for the lifetime of solid-state drives, and is faster as well.

SanskritFritz commented on 2020-11-30 20:55 (UTC)

You're right! That indeed is a regex-like expression. I simply solved this by deleting the two ini files. That brings me to another thought: I don't see the point of having two separate packages for berusky. I think I'll just simply merge the the data into the berusky2 package. What do you think?

ccorn commented on 2020-11-30 18:34 (UTC)

The idea with --no-preserve=mode is good.

However, the pattern *[^.ini] does not work as you might think. Look at man bash in the section Pathname Expansion, subsection Pattern Matching. The .ini is interpreted as a character set, not as a substring.

I assume that you want to exclude all *.ini files, which are:


Your pattern excludes the first two (and it would accidentally exclude more if e.g. some file or folder name ended in i or n), but not the third.

Therefore I propose to just copy all and then recursively search and delete the copied *.ini files from the $pkgdir tree. GNU find actually has a shortcut -delete for this. The resulting simplified commands are:

  cp --recursive --no-preserve=mode,ownership . "$pkgdir/usr/share/berusky2/"
  find "$pkgdir/usr/share/berusky2" -name '*.ini' -delete

SanskritFritz commented on 2020-11-29 17:26 (UTC)

I think I found a nice solution, check it out.

SanskritFritz commented on 2020-11-29 10:23 (UTC) (edited on 2020-11-29 17:02 (UTC) by SanskritFritz)

*[^.ini] is not a regex but a globbing expression meaning "every file except *.ini". Therefore I think my solution works well, but yours is way more readable I agree. The chmod problem seems relevant to me, I don't know how it actually worked here, I'll fix it soon.

ccorn commented on 2020-11-28 23:14 (UTC) (edited on 2020-11-28 23:15 (UTC) by ccorn)

This PKGBUILD looked wrong to me (e.g. *[^.ini] means every name ending in a character distinct from a dot, i, and n, and does not apply to subdir contents; and chmod -R -m 644 would make directory contents non-accessible). Therefore I have replaced my checkout with find and xargs commands that might actually do what seems to have been intended. I have also changed and simplified the quoting style, but that's inessential.

@@ -13,8 +13,9 @@ source=("$pkgver.tar.xz")

 package() {
-  cd "$srcdir"/"$pkgname"-"$pkgver"
-  mkdir -p "$pkgdir/usr/share/berusky2/"
-  cp -r *[^.ini] "$pkgdir/usr/share/berusky2/"
-  chmod -R 644 "$pkgdir/usr/share/berusky2/"
+  cd "$srcdir/$pkgname-$pkgver"
+  mkdir -p "$pkgdir/usr/share/berusky2"
+  cp -R . "$pkgdir/usr/share/berusky2/"
+  find "$pkgdir/usr/share/berusky2" -name '*.ini' -print0 | xargs -r0 rm -f
+  find "$pkgdir/usr/share/berusky2" -type f -print0 | xargs -r0 chmod 644

SanskritFritz commented on 2020-11-26 13:21 (UTC)

Are there significant changes? PLease, share it, yes.