[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 #46 from LINBIT <partner at linbit.com>  2009-10-16 02:48:28 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}?

Addressed succinctly by Fabio in comment #45; I have nothing to add there. :)

> - I am speaking of writing _kernel space_ related hacks on the spec
>   file (and you say this is "irrelevant for Fedora", right?)
> 
> > The alternative would be to put the kernel module build setup in a separate
> > spec, and making that available outside of Fedora -- IMHO that's clearly an
> > inferior approach in terms of accessibility.
> 
> - IMO Fedora / rpmfusion packages acutally do this approach.

That's fine, and it's certainly possible for us to do so, it's just that it
seems convenient for reviewers to be able to build both from one spec file. If
I understand Fabio correctly, his comment #45 corroborates that.

> > >   Removing parts which are not needed for Fedora will make the spec
> > >   file more readable and preferred.
> > >   ( And I think anyway this "%bcond_with km" part is completely
> > >     broken because we don't ensure that the kernel version of
> > >     the build server and of the host that the rebuilt binary rpm
> > >     is to be used is the same.
> > 
> > That's actually irrelevant; we can build the userland on any kernel, it doesn't
> > need to match that of the kernel module build.
> 
> - What I am speaking is when "--with km" is passed to your srpm
>   and not speaking about only building userland part binary rpm.
>   So if you're thinking of userland build, again "%bcond_with km"
>   is not needed.

Which is why it's disabled by default. And: it will build correctly if it finds
a kernel Makefile in /lib/modules/`uname -r`/build, which is what people get
when they just install kernel-devel and then invoke rpmbuild. It will also
build correctly in a chroot environment if passed the kernelversion and kdir
defines.

> - So this (i.e. user _has to_ build locally kernel module) is not expected
>   on Fedora."

Fully agreed, as discussed in earlier comments; it is expected that people will
use this in conjunction with a DRBD-enabled Fedora kernel. As long as DRBD is
not available in the stock Fedora kernel, people can

a) install kernel-source, patch DRBD into their kernel source checkout, and
build a kernel with a DRBD backports or

b) install drbd from a kmod build.

The drbd-km part merely provides b) as an added convenience.

> > > - Similarly, would you explain why you want to keep
> > >   %if %{without udev} part on Fedora?
> > 
> > Because users who rebuild my choose not to use the drbd udev integration
> > scripts at all? We default to what seems sensible (to us), that is, use udev,
> > but there's no reason to force this upon users, so they can and will disable
> > this if they see fit.
> 
> - So why is it needed _on Fedora_? (i.e. why do you expect that F-10/11/12/13
>   user chooses not to use udev integration scripts although all of them
>   have udev installed?)  

The udev integration scripts are not required for DRBD functionality. I.e. DRBD
will work happily not only on a non udev enabled system (clearly not expected
for Fedora), but it will also interface nicely with udev when the drbd udev
integration scripts are not installed. All the udev scripts do is install
symlinks to the DRBD devices, with user-friendly names.

So rather than unconditionally shove the udev scripts down the throat of people
who may not want them, I consider it prudent to enable them by default and
giving users the option of installing and uninstalling them separately.

-- 
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.