[Bug 187430] Review Request: elektra
bugzilla at redhat.com
bugzilla at redhat.com
Wed Apr 19 09:36:16 UTC 2006
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
Summary: Review Request: elektra
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187430
------- Additional Comments From pertusus at free.fr 2006-04-19 05:36 EST -------
(In reply to comment #19)
> I guess, I can't avoid to more direct: The amount of warnings qualifies this
> piece of SW as "not ready for public use".
>
> I would be willing to ignore them for an arbirary standard library, but I am not
> willing to ignore them for a package using DLLs, being involved into booting.
No software is forced to use elektra for booting. It will take years
before stable elements of the booting process use elektra, if it ever
happens. However for new elements in boot process I think it is not
problematic if they use an experimental piece of software - even if only
for testing.
> Yes, these packages are also suffering from DLL hell. In particular, packaging
> firefox/mozilla plugins is a PITA because of this.
I am pretty unclear on the subject, but I can't see how this may be
avoided. For non dlopended modules the library must be present during
linking, and that's what is avoided with dlopened modules. Do you mean
that dlopened modules should have a soname? But lt_dlopenext (and dlopen)
don't care about sonames? The only way I see to achieve it would be to
hardcode the version in the module name.
So it seems to me that it would be misleading to have a version information
in the file name similar with what is done for classical shared libraries
when it is ignored.
The versioning still may be achieved at runtime, by searching for some
symbols that would be present only for a given version, or use values stored
in variables to make sure that the backend version uses a given api
version. From a quick glance at the backend code this doesn't seems to
be implemented in elektra.
But I do agree with you that it won't solve the trouble for the packagers
to make sure that, at package install time the abi/api is the right one.
What solution do you have, that allows the flexibility of dlopened modules
while allowing to have a abi/api check at package? I see one, it is to have
the backend link against a specific libelektra library version. But it is
rather ugly.
> But there still is a major difference between these packages and elektra:
> They install their DLLs into /lib/<subdir> rsp. /usr/lib/<subdir>/plugins.
That I agree completly with (as can be ssen in my other comments...).
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
More information about the Fedora-package-review
mailing list