[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