You are not logged in.
Hi everyone and sorry for the newbie question.
I have been reading the Arch Wiki, AUR pages and all. There are some things that weren't very clear to me, so I dare ask here.
1- I want to make a PGKBUILD which is actually almost only gathering of a few dependencies; but these dependencies include some other AUR packages, which is why I can't test it locally before pushing anything into anywhere. Is there a way for that?
2- For the intention of the package to fulfill, a service must start, which is a red flag to put in the PKGBUILD as I gather. I saw some people adding some print lines to tell the user to enable a service. Is that the way to go?
3- Package needs the default Java version to be set to something specific, which requires sudo, which is another red flag.
4- Package needs to create a symlink in /usr/lib directory, for another file as the target in the same directory, which also requires sudo. Does PKGBUILD have this ability? Or the user must do it all manually?
To be clear, this is the PKGBUILD:
pkgname=eimza
pkgver=1.0
pkgrel=1
pkgdesc="Shorthand installation for Turkish smartcard providers (etugra, tubitak etc.)"
arch=(i686 x86_64)
#url=""
license=('BSD-3-Clause')
depends=(akia jdk17-openjdk acsccid pcsc-tools omnikey_ifdokccid opensc sac-core sac-gui icedtea-web pkcs11-helper safesign-lib)
And these are the commands that need to be executed:
systemctl enable --now pcscd.service
archlinux-java set java-17-openjdk
ln -s /usr/lib/libaetpkss.so /usr/lib/libaetpkss1.so
All seem forbidden to me
Last edited by TurabG (2025-03-04 06:24:43)
Offline
I got an answer for 1.
You can ALWAYS build locally, nothing is stopping you from installing the deps found in the AUR.
Offline
require a specific java version is bad
if your code requires some features only working in a specific major but breaks with newer versions you use some internals which should be avoided
rather set some minimum version as base line and check that your code runs properly on newer versions
in fact: unless you use the newest hottest crap its likely your code is either already compatible with way older versions or should be easily refactored
so - question comes up: what feature of java17 you rely on specifically? and wouldn't it work with newer versions?
if your answer is something in the direction of "because of some dependency" you should replace that or report an issue to its dev to fix thier code
Offline
I got an answer for 1.
You can ALWAYS build locally, nothing is stopping you from installing the deps found in the AUR.
Yes I can, but it will be a manual check of my own system only and not the PKGBUILD itself. I mean I won't know if this PKGBUILD is working for other people as intended.
require a specific java version is bad
if your code requires some features only working in a specific major but breaks with newer versions you use some internals which should be avoided
rather set some minimum version as base line and check that your code runs properly on newer versions
in fact: unless you use the newest hottest crap its likely your code is either already compatible with way older versions or should be easily refactoredso - question comes up: what feature of java17 you rely on specifically? and wouldn't it work with newer versions?
if your answer is something in the direction of "because of some dependency" you should replace that or report an issue to its dev to fix thier code
I totally agree. Requiring a specific version and not updating the code base to at least play nice with the up-to-date environment is really bad practice. The thing is, this has nothing to do with my code (I haven't written a piece of code for this build, it's just a collection of requirements to use a smartcard); this is all about smartcard providers who use specific and specifically old versions of Java. They don't update their code, but rather they force you to downgrade. They don't properly handle security requirements but instead they force you to lower the security measures on your system. Many people have to use their smartcard devices (certificates, i.e. digital signatures) for a reason which they can't avoid. For example I use it to sign documents which I need to upload to the legal system (like to add a digital document to a lawsuit) or to send registered e-mails.
Most of the public entities (of the government) also use these very old software; so the proprietary ones also don't care. I remember that rusty Microsoft Java VM die a very slow death in Turkey (like 10 years after its death in the rest of the world). So you can't usually enforce the devs fix their code on that matter and I highly doubt most of them really could. I don't know why most of the public entities insist on old and very poorly designed Java code although they have capable devs at other languages, but in the end that's the case.
Last edited by TurabG (2025-03-04 06:57:50)
Offline
well - I can think of at least one reason - but that doesn't belong here
anyway - in this case you're bound to it due to the legal stuff
I would likely setup some vm or a second insall specific put together for that use case and only use it for such - sure this will impact convenience but lowers the risk of screwing it up completely
Offline
mackin_cheese wrote:I got an answer for 1.
You can ALWAYS build locally, nothing is stopping you from installing the deps found in the AUR.
Yes I can, but it will be a manual check of my own system only and not the PKGBUILD itself. I mean I won't know if this PKGBUILD is working for other people as intended.
clean chroot building helps with that
2- For the intention of the package to fulfill, a service must start, which is a red flag to put in the PKGBUILD as I gather. I saw some people adding some print lines to tell the user to enable a service. Is that the way to go?
it's one solution and works best if the service needs to be a systemd system service.
For a systemd user service there may be better options.
3- Package needs the default Java version to be set to something specific, which requires sudo, which is another red flag.
Don't change global java default, only change it for a specific application .
https://wiki.archlinux.org/title/Java#L … va_version lists 2 methods that achieve that.
4- Package needs to create a symlink in /usr/lib directory, for another file as the target in the same directory, which also requires sudo. Does PKGBUILD have this ability? Or the user must do it all manually?
That symbolic link can be created under $pkgdir in the package function.
Something like
ln -s /usr/lib/foo $pkgdir/usr/lib/foo1
should work .
Notes :
- l tend to mix up target and link with ln, doublecheck the command does what you want.
- namcap will complain about a broken symlink during the clean chroot build .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
That symbolic link can be created under $pkgdir in the package function.
Unfortunately the smartcard applications (JARs) look for this file in /usr/lib, therefore I cannot place the file anywhere else. See, the actual file is libaetpkss.so and the app strictly wants for a libaetpkss1.so ignoring the original file itself in the very same directory; let alone for it to read it elsewhere.
For a systemd user service there may be better options.
Any place I can read further about this?
Don't change global java default, only change it for a specific application
A pretty better (and should-be-the-default) option, thank you!
I will try clean chroot building also, thank you for that too.
Last edited by TurabG (2025-03-10 09:00:45)
Offline
Lone_Wolf wrote:That symbolic link can be created under $pkgdir in the package function.
Unfortunately the smartcard applications (JARs) look for this file in /usr/lib, therefore I cannot place the file anywhere else. See, the actual file is libaetpkss.so and the app strictly wants for a libaetpkss1.so ignoring the original file itself in the very same directory; let alone for it to read it elsewhere.
On install everything under $pkgdir will be placed in the corresponding folders on the real system.
Something under $pkgdir/etc will end up in /etc .
I can't explain how & why it works, but using it is simple . Please try it.
Lone_Wolf wrote:For a systemd user service there may be better options.
Any place I can read further about this?
I try to avoid systemd user services , but https://wiki.archlinux.org/title/Systemd/User should be a good starting point.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline