Skip to content

Make libelectronic-id releases before including it into web-eid #120

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Germano0 opened this issue Mar 3, 2025 · 2 comments
Closed

Make libelectronic-id releases before including it into web-eid #120

Germano0 opened this issue Mar 3, 2025 · 2 comments

Comments

@Germano0
Copy link

Germano0 commented Mar 3, 2025

All major Linux distributions like Fedora have a policy about not having bundled libraries into the packages.
For this reason I am about to unbundle libelectronic-id from web-eid sources and package it as a separate package. However I have noticed that the libelectronic-id shipped in web-eid is not a proper release version (1.x.x) but it is just a reference to a specific commit (I.E. see https://github.com/web-eid/web-eid-app/tree/v2.6.x/lib )
I would like to ask you if you can in future web-eid releases include proper libelectronic-id releases instead of a reference to a commit.
This will make our packages maintaining tasks easier and more neat.
Cheers

@metsma
Copy link
Contributor

metsma commented Mar 3, 2025

We do not guarantee ABI/API stability for libelectronic-id, so I strongly advise against packaging it as a separate library. This is the reason behind our versioning policy.

@mrts
Copy link
Member

mrts commented Apr 7, 2025

As @metsma mentioned, we currently do not guarantee ABI/API stability for libelectronic-id as the library is treated as an internal implementation detail of the Web eID app.

Packaging it separately as a system-wide library could give the impression that it is intended for broader reuse, which is not the case at this stage. This could lead to misunderstandings and maintenance overhead both for us and downstream packagers.

Should there be a demand from external users or contributors for using this library in other applications, we can revisit this in the future. We would of course be glad to see wider adoption, but let's continue when a concrete need for the library emerges.

@mrts mrts closed this as completed Apr 7, 2025
@mrts mrts linked a pull request Apr 7, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants