Datediff script PKGBUILD review
Hello! I would like to introduce my project to the AUR mailing list. I am about to upload a PKGBUILD of a `datediff.sh' script which does calendrical calculations with shell built-ins, and has got some other few functions as well. Would installing the script as `datediff.sh' to /usr/bin be standard? Suggestions are appreciated. I am thinking about making a man page, that is why one line in package() is still commented out - but may use it in the future. # Maintainer: Jamil SN <jamilbio20@gmail.com> pkgname='datediff.sh' pkgbase='shellDatediff' pkgver=0.23.4 pkgrel=1 #epoch= pkgdesc='Calculate time differences with Ksh, Bash, and Zsh builtins. Check moon phases, Easter dates and next Friday 13th.' arch=('any') url="https://github.com/mountaineerbr/${pkgbase}" license=('GPL') depends=('bash') optdepends=( 'date: convert input to iso-8601' 'bc: fractional time units (bash)' ) provides=('datediff.sh') #conflicts=('datediff.sh') source=("https://github.com/mountaineerbr/${pkgbase}/releases/download/v${pkgver}/${pkgbase}.tar.zst") md5sums=('949f88594bba40f7a62ff65e6dda7cf8') prepare() { cd "${pkgbase}-${pkgver}" #check defaults interpreter if command -v ksh then return 0 elif command -v bash then _sh=bash elif command -v zsh then _sh=zsh else return 0 fi sed -i -e "1s/ksh/${_sh}/" "${pkgname}" } package() { cd "${pkgbase}-${pkgver}" #install -Dm644 "${pkgname}.1" "${pkgdir}/usr/local/man/man1/${pkgname}.1" install -Dm755 "${pkgname}" "${pkgdir}/usr/bin/${pkgname}" }
Hello, You can removed the commented keys because they are not going to be used if commented :P provides is not required here, as it is inferred from the package name, if the package name is equal to what it provides, it can be inferred. What is up with the different package name and package base? Package base is used for split packages, as this is not a split package what stops the pkgbase being equal to the pkgname and thus inferred? (Inferred meaning you can remove the pkgbase if it is equal to the pkgname). Ensure to test build (ideally in a clean chroot) the package before pushing to the AUR, will save you a lot of headache bumping pkgrel every time you realise the package is broken. Good luck, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
Thanks, Polarian. I thought about using pkgbase because the repo name differs from the actual script name.. But I will heed your advice and use pkgname instead, and _pkgname as the real name of the script file. On 22/03/2023 08:11, Polarian wrote:
Hello,
You can removed the commented keys because they are not going to be used if commented :P
provides is not required here, as it is inferred from the package name, if the package name is equal to what it provides, it can be inferred.
What is up with the different package name and package base?
Package base is used for split packages, as this is not a split package what stops the pkgbase being equal to the pkgname and thus inferred? (Inferred meaning you can remove the pkgbase if it is equal to the pkgname).
Ensure to test build (ideally in a clean chroot) the package before pushing to the AUR, will save you a lot of headache bumping pkgrel every time you realise the package is broken.
Good luck,
On Wed, 22 Mar 2023 08:30:25 -0300 jamil bio <jamilbio20@gmail.com> wrote:
Thanks, Polarian.
I thought about using pkgbase because the repo name differs from the actual script name.. But I will heed your advice and use pkgname instead, and _pkgname as the real name of the script file.
And why does the real script name matter at all? Please don't top post.
Hello,
And why does the real script name matter at all?
Because the current name conflicts with another packages executable within /usr/bin, so deciding on what to call the script (with or without the extension) may or may not cause confliction, which would require the addition of the conflicts key within the PKGBUILD with the value of any packages providing an executable of the same name.
Please don't top post.
What does this mean? Thanks, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
On Wed, 22 Mar 2023 13:15:43 +0000 Polarian <polarian@polarian.dev> wrote:
Hello,
And why does the real script name matter at all?
Because the current name conflicts with another packages executable within /usr/bin, so deciding on what to call the script (with or without the extension) may or may not cause confliction, which would require the addition of the conflicts key within the PKGBUILD with the value of any packages providing an executable of the same name.
All of which has nothing at all to do with what I was talking about. You cut out the quote that I was replying to and take things out of context? Come on.
Please don't top post.
What does this mean?
Google it.
Please dont top replies means whatever, Arch mail lists are generally confusing and have got some problems... On 22/03/2023 10:13, Doug Newgard wrote:
On Wed, 22 Mar 2023 08:30:25 -0300 jamil bio<jamilbio20@gmail.com> wrote:
Thanks, Polarian.
I thought about using pkgbase because the repo name differs from the actual script name.. But I will heed your advice and use pkgname instead, and _pkgname as the real name of the script file. And why does the real script name matter at all?
Please don't top post.
Would installing the script as `datediff.sh' to /usr/bin be standard?
I believe /usr/bin/datediff would. Adding the extension to the executable is non-standard, lots of binaries are plaintext, but they do not carry their extension. Imagine you rewrite your tool to use python instead, now you and everyone else who relies on the tool has to deal with the breaking change, whereas if the extension is never present, this isn't a problem. It also makes it nicer to be typed out in a terminal without having to mash TAB. However(!), datediff is already an existing tool in community/dateutils, which seems to have a similar use case as your tool does.
Suggestions are appreciated
md5 is broken and should not be used, sha256 or similar would be advised. On Wed, Mar 22, 2023 at 11:55 AM jamil bio <jamilbio20@gmail.com> wrote:
Hello!
I would like to introduce my project to the AUR mailing list. I am about to upload a PKGBUILD of a `datediff.sh' script which does calendrical calculations with shell built-ins, and has got some other few functions as well.
Would installing the script as `datediff.sh' to /usr/bin be standard?
Suggestions are appreciated. I am thinking about making a man page, that is why one line in package() is still commented out - but may use it in the future.
# Maintainer: Jamil SN <jamilbio20@gmail.com> pkgname='datediff.sh' pkgbase='shellDatediff' pkgver=0.23.4 pkgrel=1 #epoch= pkgdesc='Calculate time differences with Ksh, Bash, and Zsh builtins. Check moon phases, Easter dates and next Friday 13th.' arch=('any') url="https://github.com/mountaineerbr/${pkgbase}" license=('GPL') depends=('bash') optdepends=( 'date: convert input to iso-8601' 'bc: fractional time units (bash)' ) provides=('datediff.sh') #conflicts=('datediff.sh') source=("https://github.com/mountaineerbr/${pkgbase}/releases/download/v${pkgver}/${pkgbase}.tar.zst") md5sums=('949f88594bba40f7a62ff65e6dda7cf8')
prepare() { cd "${pkgbase}-${pkgver}"
#check defaults interpreter if command -v ksh then return 0 elif command -v bash then _sh=bash elif command -v zsh then _sh=zsh else return 0 fi
sed -i -e "1s/ksh/${_sh}/" "${pkgname}" }
package() { cd "${pkgbase}-${pkgver}"
#install -Dm644 "${pkgname}.1" "${pkgdir}/usr/local/man/man1/${pkgname}.1" install -Dm755 "${pkgname}" "${pkgdir}/usr/bin/${pkgname}" }
Hello,
However(!), datediff is already an existing tool in community/dateutils, which seems to have a similar use case as your tool does.
Well then the executable needs to be renamed, or conflicts must be added to the PKGBUILD to conflict community/dateutils
Adding the extension to the executable is non-standard, lots of binaries are plaintext, but they do not carry their extension. Imagine you rewrite your tool to use python instead, now you and everyone else who relies on the tool has to deal with the breaking change, whereas if the extension is never present, this isn't a problem.
Not always, sometimes if it is contained in the name it is fine, for example acme.sh keeps its extension because its within the actual name of the software. It would also be a good way to differentiate and prevent conflict between community/dateutils and this package.
md5 is broken and should not be used, sha256 or similar would be advised.
I do not see md5 being used within any repositories anymore, most use SHA256SUM, but some use SHA512SUM, whatever floats your bloat. -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
Adding the extension to the executable is non-standard,
Indeed Hroptatyr's 'C-code datediff' already exists in community as 'dateutils'. It is not desirable to install the datediff.sh script as 'datediff' to avoid such instance of conflict.. However, what binary name would be cool to install the script with?
However(!), datediff is already an existing tool in community/datediff
C-code datediff only accepts ISO-8601 dates, whereas the datediff.sh script warps `GNU date', if available (which usually is) to process input dates to ISO-8601 before calendrical calculations are performed, and it is verbose by defaults so you get a lot of info about any two dates instantly after typing them.
md5 is broken and should not be used, sha256 or similar would be advised.
Will use other checksum algos... Will switch to sha1. Thanks! On 22/03/2023 08:16, Martin Rys wrote:
Would installing the script as `datediff.sh' to /usr/bin be standard? I believe /usr/bin/datediff would. Adding the extension to the executable is non-standard, lots of binaries are plaintext, but they do not carry their extension. Imagine you rewrite your tool to use python instead, now you and everyone else who relies on the tool has to deal with the breaking change, whereas if the extension is never present, this isn't a problem. It also makes it nicer to be typed out in a terminal without having to mash TAB.
However(!), datediff is already an existing tool in community/dateutils, which seems to have a similar use case as your tool does.
Suggestions are appreciated md5 is broken and should not be used, sha256 or similar would be advised.
On 2023-03-22 at 08:33:59 -0300, jamil bio <jamilbio20@gmail.com> wrote:
md5 is broken and should not be used, sha256 or similar would be advised.
Will use other checksum algos... Will switch to sha1. Thanks!
SHA1 is broken. As indicated, please use SHA256 (or even SHA512).
On 22/03/2023 08:16, Martin Rys wrote:
Would installing the script as `datediff.sh' to /usr/bin be standard?
[...]
md5 is broken and should not be used, sha256 or similar would be advised.
-- I can eat glass, it does not hurt me. Dan Sommers, http://www.tombstonezero.net/dan
Hello,
Indeed Hroptatyr's 'C-code datediff' already exists in community as 'dateutils'. It is not desirable to install the datediff.sh script as 'datediff' to avoid such instance of conflict.. However, what binary name would be cool to install the script with?
Well personally I would just keep the .sh, keep it simple and prevents confusion.
C-code datediff only accepts ISO-8601 dates, whereas the datediff.sh script warps `GNU date', if available (which usually is) to process input dates to ISO-8601 before calendrical calculations are performed, and it is verbose by defaults so you get a lot of info about any two dates instantly after typing them.
Well, if it is a replacement, add "conflicts=('dateutil')" to your PKGBUILD, this will mean you will not be able to have dateutil and your package installed on the same system, but it will prevent the conflict of file names.
Will use other checksum algos... Will switch to sha1. Thanks!
I list the most common two, and you pick the least common sha xD -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
On Wed, 22 Mar 2023 07:55:44 -0300 jamil bio <jamilbio20@gmail.com> wrote:
Hello!
I would like to introduce my project to the AUR mailing list. I am about to upload a PKGBUILD of a `datediff.sh' script which does calendrical calculations with shell built-ins, and has got some other few functions as well.
Would installing the script as `datediff.sh' to /usr/bin be standard?
There's no problems leaving the .sh on there. If that's what upstream does, I would leave it.
Suggestions are appreciated. I am thinking about making a man page, that is why one line in package() is still commented out - but may use it in the future.
# Maintainer: Jamil SN <jamilbio20@gmail.com> pkgname='datediff.sh' pkgbase='shellDatediff'
This was already addressed, but don't do this. The name of the script doesn't matter here in any way.
pkgver=0.23.4 pkgrel=1 #epoch= pkgdesc='Calculate time differences with Ksh, Bash, and Zsh builtins. Check moon phases, Easter dates and next Friday 13th.' arch=('any') url="https://github.com/mountaineerbr/${pkgbase}" license=('GPL')
This isn't correct, see the license section of the PKGBUILD wiki page.
depends=('bash') optdepends=( 'date: convert input to iso-8601' 'bc: fractional time units (bash)' ) provides=('datediff.sh') #conflicts=('datediff.sh') source=("https://github.com/mountaineerbr/${pkgbase}/releases/download/v${pkgver}/${pkgbase}.tar.zst") md5sums=('949f88594bba40f7a62ff65e6dda7cf8')
prepare() { cd "${pkgbase}-${pkgver}"
#check defaults interpreter if command -v ksh then return 0 elif command -v bash then _sh=bash elif command -v zsh then _sh=zsh else return 0 fi
sed -i -e "1s/ksh/${_sh}/" "${pkgname}" }
This entire prepare function is just wrong. The PKGBUILD shouldn't be doing different things based on what random things it might find on the system.
Hello,
This isn't correct, see the license section of the PKGBUILD wiki page.
You may want to link the page (with the section you are referencing), and it is not under makepkg, it is under PKGBUILD: https://wiki.archlinux.org/title/PKGBUILD#license If you are still confused, TL;DR the licence is not included within the generic licences package, see: https://archlinux.org/packages/core/any/licenses/ This therefore means, you have to install the licence which is distributed with the source into the licence directory, under the name of the package.
This entire prepare function is just wrong. The PKGBUILD shouldn't be doing different things based on what random things it might find on the system.
I will elaborate on this a little to avoid confusion. the PKGBUILD is a file which describes how to create the package, this is done platform independently, for example when arch linux developers build packages, they are built in a clean chroot with nothing but base-devel and the dependencies needed for the package. This means including scripts inside your PKGBUILD to change how the package is built breaks the PKGBUILD and also will not work. There is the .install file, which can do modification to the host system when the package is being installed, but I do not think this will deem useful in this situation, but for more information see the man pages. Hope this helps, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
On Wed, 22 Mar 2023 13:25:06 +0000 Polarian <polarian@polarian.dev> wrote:
Hello,
This isn't correct, see the license section of the PKGBUILD wiki page.
You may want to link the page (with the section you are referencing), and it is not under makepkg, it is under PKGBUILD:
https://wiki.archlinux.org/title/PKGBUILD#license
If you are still confused, TL;DR the licence is not included within the generic licences package, see: https://archlinux.org/packages/core/any/licenses/
This therefore means, you have to install the licence which is distributed with the source into the licence directory, under the name of the package.
jamil bio, while the link here is correct, and is what I said before, the rest of it is just wrong. Ignore it.
The script should be released as KSH93 as of now, because KSH is faster than BASH or ZSH. IDK why 'community/ksh 2020.0.0-3' deems to be 'The Original AT&T Korn Shell'. That is not and it may be borked. The function declared to be futile in the preview PKGBUILD is removed. Thanks @Doug for the necessary observations. I did not know the specifics of `makepkg` in that sense. The script has been tested extensively (main fun) and its it is hardly possible that any two dates can be better processed with `C-code datediff` than with `datediff.sh`. Thanks for feedback. Further feedback and requests are mostly welcome. On 22/03/2023 10:41, Doug Newgard wrote:
On Wed, 22 Mar 2023 13:25:06 +0000 Polarian<polarian@polarian.dev> wrote:
Hello,
This isn't correct, see the license section of the PKGBUILD wiki page. You may want to link the page (with the section you are referencing), and it is not under makepkg, it is under PKGBUILD:
https://wiki.archlinux.org/title/PKGBUILD#license
If you are still confused, TL;DR the licence is not included within the generic licences package, see: https://archlinux.org/packages/core/any/licenses/
This therefore means, you have to install the licence which is distributed with the source into the licence directory, under the name of the package. jamil bio, while the link here is correct, and is what I said before, the rest of it is just wrong. Ignore it.
Or should I say 'rather' than 'hardly'.. Meaning that, possibly, `C-code datediff` does not result in better processing of date ranges than a fair comparison with the `datediff.sh` script. Cheers!
May be better to community to defaults to Ksh93u+m <https://github.com/ksh93/ksh> It is much faster when calculating very large time ranges in tests. And everyone would be more comfortable, any ways.
participants (5)
-
2QdxY4RzWzUUiLuE＠potatochowder.com
-
Doug Newgard
-
jamil bio
-
Martin Rys
-
Polarian