Dne čtvrtek 12. května 2022 13:31:14 CEST, Martin Wilck napsal(a):
On Wed, 2022-05-11 at 20:55 +0200, Florian "sp1rit" wrote:
Am Mittwoch, dem 11.05.2022 um 20:18 +0200 schrieb Lukáš Krejza:
@Sp1rit, do you plan to submit libfprint-tod to Factory? I noticed that there are some build failures for older Leap versions, but i don't know if these are required to be resolved before Factory submission.
Typically not for Factory, but AFAIK sometimes for individual devel projects. I never really intended to submit this to factory, given that it's basically just a "fork" of libfprint.
Using non-official repositories is generally discouraged. That's not my personal opinion, but frequently stated on this ML. Nothing outside of Factory (and the few semi-officially endorsed repos like packman) "exists", really, except for die-hard developers.
Lukáš' post shows that there's user interest in including the -tod release officially. Technically, that shouldn't be a big issue, it could be realized with Provides: and Conflicts: tags.
It depends on how well-maintained the upstream -tod fork is. Was it a one-time fork, or do they actively pull in fixes and changes from the libfprintd project? And it also depends on someone's (your?) willingness to take on the burden of doing the maintenance.
Fingerprint readers have the special property that every system typically has just one device, so including both would even work if libfprintd-tod supported only a subset of libfprintd's supported devices.
Regards Martin
Hey Martin, I wouldn't rush with submission to Factory yet due to few reasons: 1) We will probably change names of packages to correspond with other distros and SUSE .so lib rpm naming convention. Currently, the "-tod" fork provides both libraries ( libfprint-2.so.2.0.0 _and_ libfprint-2-tod.so.1 ). We need to split these into 2 packages and make correct dependencies, as you already mentioned. But i think, that dropping "upstream" version completely would be wrong. I have asked developer of the "-tod" fork about differences in the libfprint-2.so.2.0.0 libraries between the forks here: https:// gitlab.freedesktop.org/3v1n0/libfprint/-/issues/5 if you want follow. 2) In the mentioned bug report, I am trying to solve also a (minor) bug that I am experiencing during testing. This needs to be resolved too, before the submission. 3) Currently, Arch linux packages both versions separately, for more info, please refer here: https://wiki.archlinux.org/title/fprint . We can get some inspiration there too (except that they provide both libraries in one package for the "tod" fork too, which i would like to avoid and solve it with dependencies) 4) The libfprint-tod and libfprint libraries are fully open-source, however, "tod" fork is basically useless without the closed source driver components. Main purpose of the fork is allowing loading external drivers as a libraries that are provided by vendors. This means that it is virtually useless without submitting the drivers (to packman or as a pullin packages) 5) Actual question here: Does RPM support Provides: modalias and/or Supplements: modalias for USB IDs? I would use it for the closed driver components, if possible. Regards, Gryffus