[aur-general] New package: hubflow-git
Hi, I have submitted hubflow-git package: https://aur.archlinux.org/packages/hubflow-git/ I'd appreciate any comments and reviews. This package relies on fix in added to hubflow after my bug report: https://github.com/datasift/gitflow/issues/32 So, if anyone wants to create hubflow package for current released version, (s)he may need to patch it manually. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On 2013-03-22 20:52 +0000 Mateusz Loskot wrote:
Hi,
I have submitted hubflow-git package:
https://aur.archlinux.org/packages/hubflow-git/
I'd appreciate any comments and reviews.
This package relies on fix in added to hubflow after my bug report: https://github.com/datasift/gitflow/issues/32 So, if anyone wants to create hubflow package for current released version, (s)he may need to patch it manually.
Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Instead of "if [ -d $... ]" use "if [[ -d $... ]]" to avoid word expansion. Quote all path variables ("$srcdir" or "${srcdir}", etc.) to avoid word expansion. You can include curly brackets if you like but they serve no purpose in your PKGBUILD. They are only useful for separating variables from surrounding text (e.g. "${foo}bar") or for performing string operations (e.g. "${foo:3}"). They are not equivalent to quotes, which is how many users seem to use them. For example: bar='haha hoho' for foo in ${bar}; do echo $foo; done will echo haha hoho whereas bar='haha hoho' for foo in "$bar"; do echo $foo; done (or ...in "${bar}";) will echo haha hoho Remove the "|| return 1" statements. These are deprecated because makepkg sets the "-e" option ("set -e") and will therefore exit automatically if any errors are encountered. Instead of mkdir -p ${pkgdir}/usr/share/licenses/${pkgname} cp ${srcdir}/${_gitname}/LICENSE ${pkgdir}/usr/share/licenses/$pkgname/ use install -Dm644 "${srcdir}/${_gitname}/LICENSE" "${pkgdir}/usr/share/licenses/$pkgname/LICENSE" or install -Dm644 "$srcdir/$_gitname/LICENSE" \ "$pkgdir/usr/share/licenses/$pkgname/LICENSE" Always use "install" instead of of combinations of "mkdir", "mv", "cp" and "chmod" whenever possible. The PKGBUILD does not seem to include any binary or architecture-specific files, so you should change the "arch" array to "arch=('any')". Regards, Xyne
Xyne wrote:
use install -Dm644 "${srcdir}/${_gitname}/LICENSE" "${pkgdir}/usr/share/licenses/$pkgname/LICENSE"
or install -Dm644 "$srcdir/$_gitname/LICENSE" \ "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
The first install line was line-wrapped. It should have been one line: install -Dm644 "${srcdir}/${_gitname}/LICENSE" "${pkgdir}/usr/share/licenses/$pkgname/LICENSE"
Am Samstag 23 März 2013, 06:34:37 schrieb Xyne:
Always use "install" instead of of combinations of "mkdir", "mv", "cp" and "chmod" whenever possible.
I would go d'accord with "Always consider using 'install' vs ...". However I do not understand why one should "Always use install". And everytime I ask about the reasons, I don't get an answer, so I ask here again. I do understand that there are cases where using install is quite beneficial. That is: When you need to set certain permissions (other than read access, see below) or an execute bit. When you rename files and want to create folders at the same time. However, I get the impression TUs try to force people into using "install" even when it doesn't actually make things easier and even then this should be an optional change, not a must. I especially don't understand why "mkdir" is "evil". One example where I don't like using install -D is when that would mean giving a destination file name that is the same as the source file name, just to be able to use install's "-D" switch to create directories. Typos in that redundancy are not reported as errors and will create problems later on. Or when install would do exactly the same as a corresponding "cp" line. In that case it is up to personal preference, certainly no mistake. The only thing that would break a cp without chmod for nearly all (non-executable) files is a umask including 0004, which I would call a serious problem in the build environment. However, makepkg forces an umask of 0022 anyways. See also my statement in https://aur.archlinux.org/packages/picard-plugins/ In that case a merge request (to that package) was "taken hostage" to force changing everything to "install". I don't like the attitude of forcing volunteers to invest even more time when the original change is perfectly fine. After all, that might keep people from contributing the next time. And a merge request is not a personal request. It's a request that helps making the AUR better altogether. I might have taken that wrong, but the comment was posted right after the request. The request wasn't accepted until a day later and after I changed the PKGBUILD to "install" use. This was not the first comment pushing me to use "install" in my PKGBUILDS, but I still wait for actual reasons, other than personal preference. Don't get me wrong. "install" is a valuable tool and it should be used in Makefiles that install directly into the system (which makepkg is not) because of the reasons explained in http://en.chys.info/2009/05/install-vs-cp-and-mmap/ (and possibly umask problems) but I don't like when people pick on perfectly valid PKGBUILDs because they have a "feel" that everybody should always be using "install". It's not like package maintainers have too much time at their hands and are happy to change them just because of personal preference of people that don't have to maintain the package. -- JonnyJD
Johannes Dewender wrote:
Am Samstag 23 März 2013, 06:34:37 schrieb Xyne:
Always use "install" instead of of combinations of "mkdir", "mv", "cp" and "chmod" whenever possible.
I would go d'accord with "Always consider using 'install' vs ...". However I do not understand why one should "Always use install". And everytime I ask about the reasons, I don't get an answer, so I ask here again.
I do understand that there are cases where using install is quite beneficial. That is: When you need to set certain permissions (other than read access, see below) or an execute bit. When you rename files and want to create folders at the same time.
However, I get the impression TUs try to force people into using "install" even when it doesn't actually make things easier and even then this should be an optional change, not a must. I especially don't understand why "mkdir" is "evil".
One example where I don't like using install -D is when that would mean giving a destination file name that is the same as the source file name, just to be able to use install's "-D" switch to create directories. Typos in that redundancy are not reported as errors and will create problems later on. Or when install would do exactly the same as a corresponding "cp" line. In that case it is up to personal preference, certainly no mistake.
The only thing that would break a cp without chmod for nearly all (non-executable) files is a umask including 0004, which I would call a serious problem in the build environment. However, makepkg forces an umask of 0022 anyways.
See also my statement in https://aur.archlinux.org/packages/picard-plugins/ In that case a merge request (to that package) was "taken hostage" to force changing everything to "install". I don't like the attitude of forcing volunteers to invest even more time when the original change is perfectly fine. After all, that might keep people from contributing the next time. And a merge request is not a personal request. It's a request that helps making the AUR better altogether. I might have taken that wrong, but the comment was posted right after the request. The request wasn't accepted until a day later and after I changed the PKGBUILD to "install" use. This was not the first comment pushing me to use "install" in my PKGBUILDS, but I still wait for actual reasons, other than personal preference.
Don't get me wrong. "install" is a valuable tool and it should be used in Makefiles that install directly into the system (which makepkg is not) because of the reasons explained in http://en.chys.info/2009/05/install-vs-cp-and-mmap/ (and possibly umask problems) but I don't like when people pick on perfectly valid PKGBUILDs because they have a "feel" that everybody should always be using "install". It's not like package maintainers have too much time at their hands and are happy to change them just because of personal preference of people that don't have to maintain the package.
-- JonnyJD
Honestly, I don't have any real technical argument. Using "install" is the inherited religion and I'm not one to defend it. I will use something else if it is more convenient. As for the name redundancy, it is still less redundant than giving the full path twice (once to make it, and once to install the file). Overall I think it is better if there is at least some semblance of consistency in the way files are installed in PKGBUILDs, but that is stylistic. I can't comment on your anecdote without seeing the code and comment involved. That's all I've got. *raises hands*
On 23 March 2013 06:34, Xyne
On 2013-03-22 20:52 +0000 Mateusz Loskot wrote:
I have submitted hubflow-git package:
https://aur.archlinux.org/packages/hubflow-git/
I'd appreciate any comments and reviews.
This package relies on fix in added to hubflow after my bug report: https://github.com/datasift/gitflow/issues/32 So, if anyone wants to create hubflow package for current released version, (s)he may need to patch it manually.
Instead of "if [ -d $... ]" use "if [[ -d $... ]]" to avoid word expansion.
Fixed.
Quote all path variables ("$srcdir" or "${srcdir}", etc.) to avoid word expansion. You can include curly brackets if you like but they serve no purpose in your PKGBUILD.
Fixed.
Remove the "|| return 1" statements. These are deprecated because makepkg sets the "-e" option ("set -e") and will therefore exit automatically if any errors are encountered.
Fixed.
Instead of mkdir -p ${pkgdir}/usr/share/licenses/${pkgname} cp ${srcdir}/${_gitname}/LICENSE ${pkgdir}/usr/share/licenses/$pkgname/
use install -Dm644 "$srcdir/$_gitname/LICENSE" \ "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
Fixed.
The PKGBUILD does not seem to include any binary or architecture-specific files, so you should change the "arch" array to "arch=('any')".
Fixed. Xyne, thank you very much for valuable comments, I appreciate. All corrections have been applied and the package updated. By the way, I admit, I grabbed PKGBUILD gitflow-git and changed to fit hubflow-git package. Apparently, there are lots of PKGBUILD files of questionable quality. Would it be possible to have lint-like hook triggered on every submission? Perhaps, tools like checkbashisms would help. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
I also would recommend to change the descriptoin. The descriptoin should not contain the package name and it's quiet long. "A Git extension to make it easy to use GitFlow with GitHub." I think this would be enought. I also created my first VCS PKGBUILD yesterday, the official guides might help you to. [1][2][3] Chris [1]https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines [2]https://wiki.archlinux.org/index.php/PKGBUILD [3]https://wiki.archlinux.org/index.php/Arch_Packaging_Standards
On 23 March 2013 15:00, Christoph Seitz
I also would recommend to change the descriptoin. The descriptoin should not contain the package name and it's quiet long.
"A Git extension to make it easy to use GitFlow with GitHub." I think this would be enought.
I think this is a good idea. Done. I simply copied description from the HubFlow repository.
I also created my first VCS PKGBUILD yesterday, the official guides might help you to. [1][2][3]
Chris
[1]https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines [2]https://wiki.archlinux.org/index.php/PKGBUILD [3]https://wiki.archlinux.org/index.php/Arch_Packaging_Standards
Yes, I do read those guides and try to follow, though the art of packaging is not single step process :) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Mateusz Loskot wrote:
By the way, I admit, I grabbed PKGBUILD gitflow-git and changed to fit hubflow-git package. Apparently, there are lots of PKGBUILD files of questionable quality. Would it be possible to have lint-like hook triggered on every submission? Perhaps, tools like checkbashisms would help.
I don't know. You should ask on aur-dev. It might be interesting but it might just be annoying if it generates (too many) false positives.
participants (4)
-
Christoph Seitz
-
Johannes Dewender
-
Mateusz Loskot
-
Xyne