[Bug 527488] Review Request: drbd - drbd tools

[bugzilla at redhat.com]

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 at redhat.com>  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.