Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=527488 --- Comment #45 from Fabio Massimo Di Nitto <fdinitto@xxxxxxxxxx> 2009-10-16 01:28:30 EDT --- (In reply to comment #42) > (In reply to comment #41) > > (In reply to comment #40) > > > As one of the sponsor members I want to ask some questions before > > > someone (including) me can start review: > > > > > > - Would you explain why non-arch-independent files under /usr/lib/%{name} > > > cannot be moved to %{_datadir}? > > - Oops... I meant why "arch-independent" files under /usr/lib/%{name} > cannot be moved to %{_datadir}? > > > > They are arch-independent. All that gets installed in that directory is a > > number of shell scripts that are provided for drbd's userland callouts (which > > it fires in a number of situations, such as detecting split brain or becoming a > > synchronization target). Fabio and I have discussed this issue here; please see > > comment #16. > > - Your comment 16 does not answer my question. Usually arch-independent > files are supposed to be installed under %{_datadir}. It was comment #17: > Regarding the hardcoded-library-path I understand the issue and it's ok to have > exceptions. This is required for several other cluster packages in order to > respect OCF and other RAs standards. There are several problems moving those files in /usr/share. All cluster (or similar) related scripts and agents (or callbacks like they are called in drbd world) need to adhere to OCF and RAs standards. The OCF standards, when was written, didn't have knowledge of things like /usr/lib64 and callbacks/RAs and similar can also be binaries or a mixture of binaries and scripts. In short, given the mixed nature and that those files are always explicitly invoked within configuration files they have to be consistent across architectures (hardcoded /usr/lib vs lib/lib64) and they can't be in %{_datadir} because there could be binaries in there (there are none in drbd package now, but users can build their own custom hooks in there). The configuration needs to be exactly the same on all nodes (so even a mixture of x86 and x86_64 can't carry the lib/lib64 difference) and mostoften is syncronized automatically across nodes. This same issues has been discussed already 2/3 times for other cluster related packages and we have to accept that those packages need this (and only this) specific exception to adhere with the standards and be portable across different architectures (keeping in mind that there was no lib64 when they were written). > > > > > > - Would you explain why you want to keep "%bcond_with km" part > > > on the spec file which seems completely unneeded on Fedora > > > ( according to your comments )? > > > > Well for one thing it's positively needed for this package review, as the drbd > > backport is not in the Fedora kernel as yet. :) Fabio has pointed out (in > > comment #5 and comment #24, among others) that building the kernel module is > > irrelevant for Fedora -- but that other packages do contain userland that is > > expected to interface with a kernel feature that's not in Fedora. > > - I am speaking of writing _kernel space_ related hacks on the spec > file (and you say this is "irrelevant for Fedora", right?) It is irrelevant because they are not used by default to comply with "no kmod" policy. I agree that we could drop them at somepoint, but I found them nice to have them there and be able to build the mod and complete the runtime testing required by the review. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review