You are not logged in.

#1 2011-12-29 12:15:11

DanielOertwig
Member
Registered: 2011-12-29
Posts: 6

customizepkg-patching

Hi smile

I have create a modification / rewrite of the original customizepkg provided in the AUR. I didn't like the file syntax, so I changed it to use normal patch files instead.
So now, you have the following setup:

To modify a package (e.g. apply patches, change build() .. ) there must be a file in /etc/customizepkg.d/ named after the package you want to modify.
This file is treated as a patch file to the PKGBUILD file of the package.
So if you run yaourt -S NAME, the file /etc/customizepkg.d/NAME is applied to NAME's PKGBUILD before building.

I'm not quite sure: Is this of use to anyone (except me)? Is it worth packaging it to AUR? (If so, is the package already AUR conform? Otherwise, what do I have to change?)
I need a few opinions here smile

I've already created a package for customizepkg-patching, but since this is my first package to create, I'm not really sure if I did everything right.

Also I'm not sure about licensing? The original customizepkg is GPL, and as my script is (naturally) based on the original, I've chosen GPL, too. Furthermore, I've mentioned the original developer. Is this sufficient?

I've uploaded the .tar.gz to my webspace, if you want to try it:  http://danieloertwig.bplaced.net/custom … 0.1.tar.gz
edit: Uploaded to AUR
https://aur.archlinux.org/packages.php?ID=55405

Daniel

Last edited by DanielOertwig (2011-12-29 16:58:42)

Offline

#2 2011-12-29 14:08:36

Spyhawk
Member
Registered: 2006-07-07
Posts: 485

Re: customizepkg-patching

Hi,

Looks useful to people using customizepkg that want some standardization.

I have, however, some concern about the concept behind customizepkg itself that I've already expressed in a few other threads. Although I do understand the need to automate custom PKGBUILD from the ABS tree, using customizepkg for AUR packages looks more like a big and ugly hack to me, using a workaround instead of fixing properly the "bug" at the source. Does someone is aware of user cases where it is not preferable to upload his/her own PKGBUILD to the AUR rather than patching the file each and every time?

Last edited by Spyhawk (2011-12-29 14:25:20)

Offline

#3 2011-12-29 14:46:15

dolik.rce
Member
From: Czech republic
Registered: 2011-05-04
Posts: 43

Re: customizepkg-patching

@Daniel:
I agree that the current format of customizepkg files is ugly, but it has few advantages over patch files. The most significant is IMHO that it is aware of the context and doesn't rely on exact wording. E.g. "remove#depends#..." will work even if in future the original PKGBUILD changes the content of depends field, while patch file would not work anymore (or even could introduced silent errors in the worst case).

OTOH the patch files would be great to keep changes in build(), package() etc. What about tweaking customizepkg to use both? Let's say it would keep the current file format unchanged, plus checked for /etc/customizepkg.d/<packagename>.patch file and applied that as well? Should be quite easy to do...


@Spyhawk:
Sometimes there are changes that are meaningful only for very small amount of users. E.g. avoiding dependency on certain packages, which most user already have installed. This is most common for ABS packages, but can easily happen in AUR too, especially if you want to build a CVS based package (*-git, *-svn,...).

Offline

#4 2011-12-29 16:50:28

DanielOertwig
Member
Registered: 2011-12-29
Posts: 6

Re: customizepkg-patching

@Spyhawk:
I think that, as dolik.rce already mentioned, there is always the need for customization. Especially for small changes, e.g. like changing the configure flags, it would be really messy to have tons of packages in AUR. At least that's what I think about it.

@dolik.rce:
Oh, yes, you are probably right here. Using both was my first idea, but there are some difficulties to get this to work in a clean way:
yaourt is checking for /etc/customizepkg.d/NAME itself. So that file MUST be present, otherwise customizepkg won't be run.

Thus i have to decide what contents get into that file: It's either a patch OR a file with "old" format.

The problem in applying both that I see is the following:
To get rid of the problematic of changing PKGBUILD format, the patch needs to be applied only to build() etc. but not to e.g. the depends field.
Honestly, I don't know how this can be accomplished. Splitting the file may be possible, but on the other hand, it then requires splitting the file when creating the patch, too.
Furthermore, using both mechanisms leaves me to decide: which one first, and what to do in conflicts.

So I don't know how this should look like. That is probably because I don't have much experience with the Arch package system and the most common use cases of such modifications yet.
Does someone have examples of how they customized a PKGBUILD?

One thing that comes to my mind is, that it should be easy to implement to first try to use the file as a patch, and, if that does not succeed, to use it with the "old" format.
That gives the ability to use both formats, but not both for one package.
What do you think about that approach?

Offline

#5 2011-12-29 18:05:28

dolik.rce
Member
From: Czech republic
Registered: 2011-05-04
Posts: 43

Re: customizepkg-patching

DanielOertwig wrote:

Oh, yes, you are probably right here. Using both was my first idea, but there are some difficulties to get this to work in a clean way:
yaourt is checking for /etc/customizepkg.d/NAME itself. So that file MUST be present, otherwise customizepkg won't be run.

Thus i have to decide what contents get into that file: It's either a patch OR a file with "old" format.

The problem in applying both that I see is the following:
To get rid of the problematic of changing PKGBUILD format, the patch needs to be applied only to build() etc. but not to e.g. the depends field.
Honestly, I don't know how this can be accomplished. Splitting the file may be possible, but on the other hand, it then requires splitting the file when creating the patch, too.
Furthermore, using both mechanisms leaves me to decide: which one first, and what to do in conflicts.

So I don't know how this should look like. That is probably because I don't have much experience with the Arch package system and the most common use cases of such modifications yet.
Does someone have examples of how they customized a PKGBUILD?

One thing that comes to my mind is, that it should be easy to implement to first try to use the file as a patch, and, if that does not succeed, to use it with the "old" format.
That gives the ability to use both formats, but not both for one package.
What do you think about that approach?

I'd love to have the best of both worlds smile You are right about the fact that yaourt expects only one of the files, so my proposed solution is not applicable. But there is different way with equal functionality: Extend the format of the file to allow it to include patches. Now there are the "add", "delete" and "replace" directives, with well defined meanings and syntax. The file format could be extended to accept anything else as a patch. Then it could be applied with command similar to this:

sed '/^\(add\)\|\(replace\)\|\(remove\)\|\(\)#/d' | patch -p1

I'm not sure how much changes would be necessary in the customizepkg code, but I guess it should be enough to make it ignore the unrecognized lines.

Concerning possible conflicts: I would't be afraid of that, since in most cases the old-style changes would act on variables, while the patches would only touch the build and package functions so the conflicts should be rare. The order of changes doesn't matter too much for the same reason, but I'd recommend doing the patch part first, in order not to confuse the patch program with possibly changed line numbers. The customizepkg replacements are aware of the context, so they don't care if the positions have changed.

Offline

#6 2013-03-11 14:34:03

fradeve
Member
Registered: 2013-01-24
Posts: 9

Re: customizepkg-patching

Hi,
I'm trying to use customizepkg-patching with VIM from the Herecura repo.

The problem is that VIM has one PGKBUILD and multiple output packages (`vim-cli`, `vim-rt`): I can place the PKGBULD patch in `/etc/customizepkg.d/vim` but will never be correspondence between the patch name and packages names, since I'm currently installing

herecura-stable/vim-cli
herecura-stable/vim-rt

I haven't tried customizepkg-new, is there any chance to get this to work?

Offline

#7 2013-04-24 16:03:19

ackalker
Member
Registered: 2012-11-27
Posts: 201

Re: customizepkg-patching

@DanielOertwig
Thanks for this very useful utility :-)

I've created a small(ish) patch adding the ability to customize any file in the directory containing the PKGBUILD.
Also, it adds:
- editing of the customized files (with vimdiff if desired)
- reviewing the patch (and saving it to the configdir if desired)
It uses functionality which patch already has for testing the patch and for backing up original files.
Hope you like it, I've been using this with much pleasure ;-)

diff -uprN customizepkg-patching.original/AUTHORS customizepkg-patching/AUTHORS
--- customizepkg-patching.original/AUTHORS	2011-12-29 12:56:08.000000000 +0100
+++ customizepkg-patching/AUTHORS	2013-04-24 17:52:07.503109663 +0200
@@ -17,3 +17,4 @@
 
 
 Daniel Oertwig <Daniel.Oertwig@googlemail.com>
+Alain Kalker <a.c.kalker@gmail.com>
diff -uprN customizepkg-patching.original/customizepkg customizepkg-patching/customizepkg
--- customizepkg-patching.original/customizepkg	2011-12-29 12:56:08.000000000 +0100
+++ customizepkg-patching/customizepkg	2013-04-24 17:18:30.770556445 +0200
@@ -31,22 +31,29 @@ print_usage()
 {
   echo "customizepkg - patching version $ver"
   echo
-  echo "Without any option, this script reads PKGBUILD from the current directory and shows a diff"
-  echo "between the original and the customized version of the file."
+  echo "Without any option, this script reads files from the current directory and shows a diff"
+  echo "between the original and the customized version of the files."
   echo "The patch to apply the changes is read from /etc/customizepkg.d/\$pkgname"
   echo
   echo "usage: customizepkg <option>"
   echo
   echo "customizepkg --version, -V       Shows version"
   echo "customizepkg --help, -h          Shows this help"
-  echo "customizepkg --modify, -m        Apply the modifications"
+  echo "customizepkg --edit, -e          Edit files marked for customization"
+  echo "                                 (add -v to edit with vimdiff)"
+  echo "customizepkg --patch, -p         Review patch (add -m to save)"
+  echo "customizepkg --modify, -m        Apply the saved modifications"
   echo "customizepkg --vimdiff, -v       Show diff using vimdiff"
   echo
-  echo "To patch, use:"
-  echo "diff -up oldPKGBUILD newPKGBUILD > /etc/customizepkg.d/\$pkgname"
-  echo "or"
-  echo "svn diff changedPKGBUILD > /etc/customizepkg.d/\$pkgname"
-  echo "or any other similar method."
+  echo "To customize a file, use:"
+  echo "$ cp file file.original"
+  echo "then edit file."
+  echo
+  echo "To add a file, create and edit it, then use:"
+  echo "$ touch file.original"
+  echo
+  echo "To remove a file, use:"
+  echo "$ mv file file.original"
   echo
   echo "Written by Daniel Oertwig <Daniel.Oertwig@googlemail.com>"
   echo "      homepage: http://www.proggen.org"
@@ -72,6 +79,8 @@ print_version()
 #-----------------------------------------------------------------------#
 VIMDIFF=0
 MODIFY=0
+PATCH=0
+EDIT=0
 
 
 
@@ -87,6 +96,12 @@ while [[ "$#" != "0" ]]; do
       print_version
       exit 0
       ;;
+    -e|--edit)
+      EDIT=1
+      ;;
+    -p|--patch)
+      PATCH=1
+      ;;
     -m|--modify)
       MODIFY=1
       ;;
@@ -109,36 +124,80 @@ source ./PKGBUILD || exit 1
 
 
 
-# Ensure there is a patch available in the configdir
-# to patch the PKGBUILD with!
-if [[ ! -r "/etc/customizepkg.d/$pkgname" ]]; then
-  echo "No configuration for $pkgname in /etc/customizepkg.d"
-  exit 1
+# Perform an action on each pair of original and
+# changed files.
+shopt -s nullglob
+for_changes_do() {
+  for f in ./*.original; do
+    "$@" "$f" "${f%.original}"
+  done
+}
+
+
+
+# Edit customized files, with vimdiff if the VIMDIFF
+# option was given, or with the editor specified by
+# EDITOR (falling back on vi) otherwise.
+if [[ "$EDIT" == "1" ]]; then
+  if [[ "$VIMDIFF" == "1" ]]; then
+    edit="vim -d"
+  else
+    edit="${EDITOR:-vi}"
+  fi
+  for_changes_do $edit
+  exit 0
 fi
 
 
 
-# Save the original PKGBUILD!
-cp ./PKGBUILD ./PKGBUILD.original
+# Show a patch with the current modifications.
+# If the MODIFY option was given, also write it to the
+# configdir.
+if [[ "$PATCH" == "1" ]]; then
+  for_changes_do diff -upN |
+    if [[ "$MODIFY" == "1" ]]; then
+      tee "/etc/customizepkg.d/$pkgname"
+    else
+      cat
+    fi
+  exit 0
+fi
 
 
 
-# Apply the patch. Revert changes if something goes
-# wrong.
-patch ./PKGBUILD "/etc/customizepkg.d/$pkgname"
-if [[ "$?" != "0" ]]; then
-  mv ./PKGBUILD.original ./PKGBUILD
+# Ensure there is a patch available in the configdir!
+if [[ ! -r "/etc/customizepkg.d/$pkgname" ]]; then
+  echo "No configuration for $pkgname in /etc/customizepkg.d"
+  exit 1
+fi
+
+
+
+# Test the patch. Apply it only if it passes.
+if ! patch --dry-run -s -i "/etc/customizepkg.d/$pkgname"; then
   echo "Patching failed!"
   exit 1
 fi
+patch -b -z .original -i "/etc/customizepkg.d/$pkgname"
 
 
 
 # Show the diffs
 if [[ "$VIMDIFF" == "1" ]]; then
-  vim -d ./PKGBUILD ./PKGBUILD.original
+  for_changes_do vim -d
+else
+  for_changes_do diff -upN
 fi
-diff -Naur ./PKGBUILD.original ./PKGBUILD
+
+
+
+# Revert a modification.
+# If the original file is empty, it means that
+# a new file was created by the patch, so remove it.
+revert() {
+  mv -f "$1" "$2"
+  [[ -s "$2" ]] || rm "$2"
+}
 
 
 
@@ -146,7 +205,7 @@ diff -Naur ./PKGBUILD.original ./PKGBUIL
 # modified file stays. Otherwise, the original
 # file is used.
 if [[ "$MODIFY" == "0" ]]; then
-  mv ./PKGBUILD.original ./PKGBUILD
+  for_changes_do revert
 fi
 
 

Offline

#8 2013-05-02 08:31:57

DanielOertwig
Member
Registered: 2011-12-29
Posts: 6

Re: customizepkg-patching

Hi smile

Sorry for the late reply. First of all I need to say that I am currently not using yaourt or customizepkg for myself.

@ackalker: I took your patch and applied it. But it seems that your patch is missing some (the last) lines, so the last hunk couldnt be applied by patch, which is why I had to do the changes by hand. Could you check that I made no mistakes?

@fradeve: This is probably an issue with all split packages. I don't know whether or how customizepkg-new is handling this. As there is only one PKGBUILD file (or now, build directory) for those vim packages, the clean (and correct) solution would be to have /etc/customizepkg.d/vim. But because yaourt is (probably still) looking for a /etc/customizepkg.d/$pkgname the customizepkg script won't even be run. I will try to fix this, but it could take a while.

Btw, I didn't use a VCS when i forked from customizepkg, but now there is a repo on github: https://github.com/DanielOertwig/customizepkg-patching

Offline

#9 2013-05-04 09:58:26

ackalker
Member
Registered: 2012-11-27
Posts: 201

Re: customizepkg-patching

@DanielOertwig
Glad you liked my patch smile and sorry for my bad paste.
I've gone ahead and made a couple more changes, and since you now have a Git repo, I'll make a pull request for you to review.
Thanks again!

Offline

Board footer

Powered by FluxBB