Hello, Could anyone who has experience with AUR packages please check over the PKGBUILD I have submitted to the AUR. It works, and I have already written up the ArchWiki page for it (https://wiki.archlinux.org/title/Eureka) but I want a second set of eyes to read through my work to ensure I have not screwed anything up, and to ensure my package is sticking to conventions (and in case anyone has any improvements). You can either read it from the git interface provided by the AUR (this can be a little annoying) or you can read it on the git repository which is hosted elsewhere here: https://onedev.polarian.dev/aur/eureka-notes/~files/master/PKGBUILD Any issues with the package let me know :) Thank you, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
On Mon, 23 Jan 2023 23:36:34 +0000 Polarian <polarian@polarian.dev> wrote:
Hello,
Could anyone who has experience with AUR packages please check over the PKGBUILD I have submitted to the AUR.
It works, and I have already written up the ArchWiki page for it (https://wiki.archlinux.org/title/Eureka) but I want a second set of eyes to read through my work to ensure I have not screwed anything up, and to ensure my package is sticking to conventions (and in case anyone has any improvements).
You can either read it from the git interface provided by the AUR (this can be a little annoying) or you can read it on the git repository which is hosted elsewhere here: https://onedev.polarian.dev/aur/eureka-notes/~files/master/PKGBUILD
Any issues with the package let me know :)
Thank you,
pkgver should not have the leading 'v'. No reason to specify pkgbase here, but it's not a problem. Is git really needed at build time? You need to rename the source archive, the name is too generic. See the warning at https://wiki.archlinux.org/title/PKGBUILD#source You need to install the license file. For rust PKGBUILDs, see https://wiki.archlinux.org/title/Rust_package_guidelines Hope this helps!
On Mon, 23 Jan 2023 18:08:04 -0600 Doug Newgard <dnewgard@outlook.com> wrote:
On Mon, 23 Jan 2023 23:36:34 +0000 Polarian <polarian@polarian.dev> wrote:
Hello,
Could anyone who has experience with AUR packages please check over the PKGBUILD I have submitted to the AUR.
It works, and I have already written up the ArchWiki page for it (https://wiki.archlinux.org/title/Eureka) but I want a second set of eyes to read through my work to ensure I have not screwed anything up, and to ensure my package is sticking to conventions (and in case anyone has any improvements).
You can either read it from the git interface provided by the AUR (this can be a little annoying) or you can read it on the git repository which is hosted elsewhere here: https://onedev.polarian.dev/aur/eureka-notes/~files/master/PKGBUILD
Any issues with the package let me know :)
Thank you,
pkgver should not have the leading 'v'.
No reason to specify pkgbase here, but it's not a problem.
Is git really needed at build time?
You need to rename the source archive, the name is too generic. See the warning at https://wiki.archlinux.org/title/PKGBUILD#source
You need to install the license file.
For rust PKGBUILDs, see https://wiki.archlinux.org/title/Rust_package_guidelines
Hope this helps!
Oh, I also forgot, it is strongly suggested that non-standard variables begin with an underscore to make sure they don't conflict with anything makepkg uses.
Hello,
Oh, I also forgot, it is strongly suggested that non-standard variables begin with an underscore to make sure they don't conflict with anything makepkg uses.
I have seen this in other PKGBUILDs but I was not sure if it was conventional or not, thanks for clearing that up for me. -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
Hello,
pkgver should not have the leading 'v'.
Packages are supposed to maintain the same version format as the upstream codebase, as the upstream uses vx.x.x the v should be added, although this will be reworked in the next commit anyways so don't worry about it.
No reason to specify pkgbase here, but it's not a problem.
Yes I am aware, I did it without thinking to be honest, I tend to declare the pkgbase and pkgname without thinking about whether the value is redundant (in the case of pkgbase).
Is git really needed at build time?
Nope, originally I was going to clone and checkout the tag, then I realised that git provides .tar.gz for source, which would be 100x easier than cloning the repository (also has lower overhead, and takes up less bandwidth). It is however needed for runtime, so I need to move this to depends, this will be done in the next commit.
You need to rename the source archive, the name is too generic. See the warning at https://wiki.archlinux.org/title/PKGBUILD#source
I was informed of this by T.J, I will be fixing this in the next commit.
You need to install the license file.
Eh, this one I was not sure about, it uses a generic license and as far as I have seen on the AUR, people do not install copies of generic licenses, because they are generic and already provided by the arch base.
For rust PKGBUILDs, see https://wiki.archlinux.org/title/Rust_package_guidelines
I will check this out, thanks for the link. Thank you, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
On Tue, 24 Jan 2023 00:17:43 +0000 Polarian <polarian@polarian.dev> wrote:
Hello,
pkgver should not have the leading 'v'.
Packages are supposed to maintain the same version format as the upstream codebase, as the upstream uses vx.x.x the v should be added, although this will be reworked in the next commit anyways so don't worry about it.
No idea where you got that idea. The v should *not* be there.
You need to install the license file.
Eh, this one I was not sure about, it uses a generic license and as far as I have seen on the AUR, people do not install copies of generic licenses, because they are generic and already provided by the arch base.
Except MIT is *not* a generic license. See the PKGBUILD wiki page again.
Hi, In addition of everything Doug said, I'd add that you don't need to specify "$srcdir" in your `cd` and `install` commands since "cd" into the "srcdir" is always implied in PKGBUILDs' functions: ``` build() { cd "$name-$version" cargo build --release } package() { install -Dm755 "$name-$version/target/release/$name" "$pkgdir/usr/bin/$name" } ``` /On a side note, I left a comment on the webAUR page of the "movim" package you maintain with suggestions to improve the PKGBUILD as well. I hope this helps :)/ -- Regards, Antiz (Robin C.)
Hello,
In addition of everything Doug said, I'd add that you don't need to specify "$srcdir" in your `cd` and `install` commands since "cd" into the "srcdir" is always implied in PKGBUILDs' functions:
I did not know that, that is some useful advice thanks, makes things a lot easier. I see a lot of packages cd'ing into the directory before building, but obviously they were not aware of this. I will add this to the next commit.
On a side note, I left a comment on the webAUR page of the "movim" package you maintain with suggestions to improve the PKGBUILD as well. I hope this helps :)
Don't worry, I am very active when it comes to responding to queries and comments, I saw it and already replied before replying to this email. I would like to point out, I am only the adopter of the package, I have yet to change a single part of the package (well I have but not committed it) as the package is a lot worse off than it seems at first glance (I know you read my posts to the AUR pep. but the package you wrote up has a lot of issues, T.J can't build it in a clean chroot either which probably means a dependency issue). I split my time across AUR and ArchWiki, I like to always document the packages I submit, in the case of Eureka I mostly spent the time on the ArchWiki adding a page for it. As for why I added the package, I check the ArchWiki list of applications quite often, and I filtered out any applications which do not currently have a package, and I decided to package Eureka as its a simple utility so it wouldn't be as difficult as the current two packages I am trying to get working, which is the Onedev package which has issues with updating to the new version (I have a separate post about this issue) and Movim which has permission issues, and also the PKGBUILD needs reworking, so taking on an easier package was my idea of trying to get a single working package under my name, as all the others are in different stages of broken! Thank you for the support, and sorry I went on a little rant, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
Hello,
No idea where you got that idea. The v should *not* be there.
Lots of AUR packagers do it, so I assumed it was conventional by that, but I guess this is just a common misconception and a trap I have fallen into too, I will fix this in the next commit, sorry for my stupid mistake.
Except MIT is *not* a generic license. See the PKGBUILD wiki page again.
Whoops, my mistake, I thought any license which was not listed as "custom" was considered generic, but obviously not, again I will fix this in the next commit. Thanks for the support, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
Hello All, I have attempted to combine all of your suggestions into one, I have followed to the rust packaging guidelines which was linked, and I have taken into consideration all the other suggestions you have made. https://onedev.polarian.dev/aur/eureka-notes/~files/master/PKGBUILD Or check the AUR package to read the source. T.J I did not include your diff cause it did not build on my system, and secondly because it does not follow the rust packaging guidelines. According to the guidelines, this should compile within the chroot you built it in T.J. Any more issues please let me know! Thanks, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
Le 24/01/2023 à 12:44, Polarian a écrit :
Hello All, Hi,
I have attempted to combine all of your suggestions into one, I have followed to the rust packaging guidelines which was linked, and I have taken into consideration all the other suggestions you have made.
https://onedev.polarian.dev/aur/eureka-notes/~files/master/PKGBUILD
Or check the AUR package to read the source.
Looks better now ;) While this is not mandatory, here are 2 suggestions I could eventually make: - Declare a custom `_pkgname=eureka` variable (since it's the real name of the software) and make use of that variable instead of repeating "eureka" multiple times in the PKGBUILD - There are still some useless usages of the `$srcdir` variable in the `install` commands inside the `package ()` function (since PKGBUILDs' functions implicitly and automatically "cd" into "srcdir" by default) As I said, those points are not mandatory. That's mostly style changes, it's up to you to decide whether you want to implement them or not I guess. Other than that, I think the PKGBUILD looks good that way. -- Regards, Antiz (Robin C.)
Hello,
While this is not mandatory, here are 2 suggestions I could eventually make: - Declare a custom `_pkgname=eureka` variable (since it's the real name of the software) and make use of that variable instead of repeating "eureka" multiple times in the PKGBUILD
You guys are laughable, Robin says to use a variable, and T.J says that using the variable is redundant and recommended me to remove it, so which should I do? You all have different ideas on what a PKGBUILD should look like and I am unsure which way I should do it :/
- There are still some useless usages of the `$srcdir` variable in the `install` commands inside the `package ()` function (since PKGBUILDs' functions implicitly and automatically "cd" into "srcdir" by default)
Whoops, forgot to remove them, let me try removing and building it and then committing it if they aren't needed. Thanks for the suggestion.
As I said, those points are not mandatory. That's mostly style changes, it's up to you to decide whether you want to implement them or not I guess. Other than that, I think the PKGBUILD looks good that way.
Thanks for the help Robin, highly appreciated! -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
Le 24/01/2023 à 13:33, Polarian a écrit :
Hello,
While this is not mandatory, here are 2 suggestions I could eventually make: - Declare a custom `_pkgname=eureka` variable (since it's the real name of the software) and make use of that variable instead of repeating "eureka" multiple times in the PKGBUILD
You guys are laughable, Robin says to use a variable, and T.J says that using the variable is redundant and recommended me to remove it, so which should I do? You all have different ideas on what a PKGBUILD should look like and I am unsure which way I should do it :/
As I said, this is mostly a "style" choice, it is up to the maintainer to adopt the use of such variables or not. Some prefer using them (like I do, because I tend to find that it makes the PKGBUILD more "portable" as you can keep the same structure for another package by just modifying the top variables' value) and some don't (as it could be redundant and it eventually makes some information more difficult to read at first glance) but, as far as I know, there's no real stated rule about this (please, someone correct me if I'm wrong about that). So once again, I think this is up to you. If you also think that using such variables is redundant, you don't have to use them ;) By the way, I wasn't aware of T.J.'s recommandations since they don't seem to appear in this discussion thread?
- There are still some useless usages of the `$srcdir` variable in the `install` commands inside the `package ()` function (since PKGBUILDs' functions implicitly and automatically "cd" into "srcdir" by default)
Whoops, forgot to remove them, let me try removing and building it and then committing it if they aren't needed. Thanks for the suggestion.
As I said, those points are not mandatory. That's mostly style changes, it's up to you to decide whether you want to implement them or not I guess. Other than that, I think the PKGBUILD looks good that way.
Thanks for the help Robin, highly appreciated!
You're welcome :) -- Cordialement, Robin Candau-
Hello,
As I said, this is mostly a "style" choice, it is up to the maintainer to adopt the use of such variables or not.
Some prefer using them /(like I do, because I tend to find that it makes the PKGBUILD more "portable" as you can keep the same structure for another package by just modifying the top variables' value)/ and some don't /(as it could be redundant and it eventually makes some information more difficult to read at first glance) /but, as far as I know, there's no real stated rule about this (please, someone correct me if I'm wrong about that).
So once again, I think this is up to you. If you also think that using such variables is redundant, you don't have to use them ;)
This is going to sound very autistic but I like the structure of using variables to substitute in the name of the package, I only removed it because T.J is a TU and I took his advice as the conventional approach.
By the way, I wasn't aware of T.J.'s recommandations since they don't seem to appear in this discussion thread?
Ah, I forgot to mention he emailed me off-list, but he provided some suggestions and diff's for helping the solution. Thank you for the support, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
Le 24/01/2023 à 14:16, Polarian a écrit :
Hello,
As I said, this is mostly a "style" choice, it is up to the maintainer to adopt the use of such variables or not.
Some prefer using them /(like I do, because I tend to find that it makes the PKGBUILD more "portable" as you can keep the same structure for another package by just modifying the top variables' value)/ and some don't /(as it could be redundant and it eventually makes some information more difficult to read at first glance) /but, as far as I know, there's no real stated rule about this (please, someone correct me if I'm wrong about that).
So once again, I think this is up to you. If you also think that using such variables is redundant, you don't have to use them ;)
This is going to sound very autistic but I like the structure of using variables to substitute in the name of the package, I only removed it because T.J is a TU and I took his advice as the conventional approach.
By the way, I wasn't aware of T.J.'s recommandations since they don't seem to appear in this discussion thread?
Ah, I forgot to mention he emailed me off-list, but he provided some suggestions and diff's for helping the solution. I mean, taking TU's advice as a conventional approach is undoubtedly a good practice!
I suggested that because, as far as I know, there's no stated rule about this specific point and, as I mentioned, I wasn't aware of T.J.'s recommandations regarding this. But yeah, if anyone has more info about that, feel free to add precision or correct me obviously! :)
Thank you for the support,
You're welcome. -- Regards, Antiz (Robin C.)
Le 24/01/2023 à 13:33, Polarian a écrit :
Hello,
While this is not mandatory, here are 2 suggestions I could eventually make: - Declare a custom `_pkgname=eureka` variable (since it's the real name of the software) and make use of that variable instead of repeating "eureka" multiple times in the PKGBUILD
You guys are laughable, Robin says to use a variable, and T.J says that using the variable is redundant and recommended me to remove it, so which should I do? You all have different ideas on what a PKGBUILD should look like and I am unsure which way I should do it :/ As I said, this is mostly a "style" choice, it is up to the maintainer to adopt the use of such variables or not.
Some prefer using them /(like I do, because I tend to find that it makes the PKGBUILD more "portable" as you can keep the same structure for another package by just modifying the top variables' value)/ and some don't /(as it could be redundant and it eventually makes some information more difficult to read at first glance) /but, as far as I know, there's no real stated rule about this (please, someone correct me if I'm wrong about that). So once again, I think this is up to you. If you also think that using such variables is redundant, you don't have to use them ;) /By the way, I wasn't aware of T.J.'s recommandations since they don't seem to appear in this discussion thread?/
- There are still some useless usages of the `$srcdir` variable in the `install` commands inside the `package ()` function (since PKGBUILDs' functions implicitly and automatically "cd" into "srcdir" by default)
Whoops, forgot to remove them, let me try removing and building it and then committing it if they aren't needed. Thanks for the suggestion.
As I said, those points are not mandatory. That's mostly style changes, it's up to you to decide whether you want to implement them or not I guess. Other than that, I think the PKGBUILD looks good that way.
Thanks for the help Robin, highly appreciated!
You're welcome :) -- Cordialement, Robin Candau
Hello, I have taken the feedback from the 2nd revision, and also removed T.Js redundant dependency he gave me (clang) from the makedepends, you can view the PKGBUILD on the aur or here: https://onedev.polarian.dev/aur/eureka-notes/~files/master/PKGBUILD I have built this in a clean chroot, now that I have resolved my chroot dilemma as you would have seen in a separate thread, I can properly test my packages. As long as the syntax of the PKGBUILD is up to standard, it should be good right? Final feedback would be nice! Thanks, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev
participants (4)
-
Doug Newgard
-
Polarian
-
Robin Candau
-
Robin Candau