On Mon, 23 Jan 2023 18:08:04 -0600 Doug Newgard wrote:

On Mon, 23 Jan 2023 23:36:34 +0000 Polarian 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,

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

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,

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

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.)

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-

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.)