https://bugzilla.redhat.com/show_bug.cgi?id=1481324 --- Comment #20 from Tomasz Kłoczko <kloczko.tomasz@xxxxxxxxx> --- (In reply to Jan Pazdziora from comment #19) > I haven't changed my opinion WRT the consistency and no bad surprises for > people who try to build modules. But of course, if the culprit was > XML::LibXSLT's use of libs and perl-devel should be consistent with perllibs > rather than libs, going with that would make sense. So .. for example now Fedora perl is replacing libbind by libresolve (perl-5.10.0-libresolv.patch). Should I ask "why this libresolve change was not pushed back to perl source code?" or "why after many changes in perl code in mean time still this patch is maintained in Fedora?" :) Because libswanted is present in $Config someone may use it as list of libraries to link perl module DSO. Someone may relay on some part of libbind which are not common with libresolve. Isn't it? It was calculated risk .. and this change IMO is OK because is fixing completely useless part of the dependencies. An I right? :) Problem with perl development resources like $Config is that this variable have no well defined propose. In most cases it simple preserves what was detected during perl build. Propose all those variables is store state of the build system on which perl is build. In other words $Config is not only extensions API interface.It preserves many things on which none of the extensions should rely. Isn't it? IMO none of the external perl modules should blindly use those perl build stages states to build own executable code like DSOs. In mean time many people started using some bits only because full $Config is installed by perl install procedures. Theoretically modules should rely only on libperl and when this library is shared form building/linking your own extensions should not be a problem. On many system libperl is installed as static library and this makes things much more complicated to implement in perl extensions build frameworks. Things are even more complicated because as you know the same code is used by many OSes. If you need something line gethistbyname() you should check is this routine is on you system where you are building perl extension in libc or libnsl like it is on Solaris which is affection libs and perllibs on Linux. On some *BSDs many glibc libm routines are in system libc. Problem is that perl modules build frameworks are very primitive. Mentioned here XML::LibXSLT uses for example additionally pkgconfig because standard perl framework would make checking availability of the devel resources of libxstl library quite hard (and of course it is nothing wrong with this). I'm not trying to discover the wheel but only underline some exact context. Again: problem is that perl provides not so sophisticated base frameworks to do such detection during perl extensions build time. By this many extensions developers are using what they are able to use and by this they are using part of the $Config which are not been designed for such proposes as something like platform for such proposes. This "s*t already happened" ;) and people like you must deal with this :( So current Fedora perl-5.10.0-libresolv.patch falsificates your statement about preserving some fixed level of the consistency or at last it makes not as strong as it was in your comment :) Again: IMO best would be drop or even try to remove something like libs, libswanted or perllib variables from $Config as at least kind of experiment to identify/expose by experiment those perl modules which are relaying on what perl detected on own executables build stage or how widely those bits are used now. However all above is completely off the scope of this ticket and does not need to be discussed here longer. So guys please focus on the ticket :) Going back to the subject of this thicket: gdbm-devel and libdb-devel can be removed NOW from Fedora perl-devel dependencies because original not patched perl source code is not using those libraries in $Config variables which could be used bu some extensions. The same is with perl header files. If some extensions are (still) using those libraries presence in $Config perl developers *already made the decision* that if someone will be expecting those libraries in $Config this is not ThePerlProblem(tm). -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ perl-devel mailing list -- perl-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to perl-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
