[Bug 226134] Merge Review: mdadm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Merge Review: mdadm


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226134


dledford@xxxxxxxxxx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |ASSIGNED
               Flag|needinfo?(dledford@xxxxxxxxx|
                   |m)                          |




------- Additional Comments From dledford@xxxxxxxxxx  2007-04-16 20:18 EST -------
W: mdadm unversioned-explicit-obsoletes mdctl
W: mdadm unversioned-explicit-obsoletes raidtools
-> As far as I have understood, these tools are gone for good, so this could be OK
  If very very sure that none of these will ever come back, it's OK, but most
probably a versioning measure should be put in place

These are most definitely gone forever.  The ioctls that the raidtools use are
being phased out of the kernel entirely, and mdctl was basically the first
version of mdadm and the name was changed later.  However, just in the last
month I had to do a new update to raidtools for a bug fix for a commercial
package that depended on raidtools, so I'm leary of hard coding the values since
they *might* change on something like an older RHEL but we still want them to be
obsoleted on upgrade to later RHEL or Fedora.

Tab/spaces fixed.

Changed summary and description so they start capitalized.

In regards to /var/run/mdadm (I didn't make the change and don't fully know why
it was necessary), here's the changelog:

* Fri Jul 30 2004 Dan Walsh <dwalsh@xxxxxxxxxx> 1.5.0-11
- Create a directory /var/run/mdadm to contain mdadm.pid
- This cleans up SELinux problem

I'm guessing that the permissions on the dir are to avoid possible cross context
contamination since mdadm has it's own context in SELinux policy.

As for the mdadm.conf-example timestamp, you're right that it's because of the
email patch.  But, that then raises the question of whether or not the timestamp
should be preserved since the file no longer matches the original tarball file.
 The patch was originally done because the default install of mdadm copied the
mdadm.conf-example to /etc and we wanted a working MAILADDR.  However, now a
days, Anaconda custom writes the mdadm.conf on install, so we don't even package
an /etc/mdadm.conf file in the rpm.  As a result, it's safe to drop the email
patch entirely, so we will no longer be modifying the file, and the timestamp
should come out correct now.

[*] There is one static compiled binary but it is needed so this should be
considered an exception to normal policy of a separate -static package.

Actually, there are two: mdadm.static and mdassemble.static (we don't even
include the shared version of mdassemble).  However, these are both intended for
use by mkinitrd to create initrd images and therefore *need* to be static, so I
do think they both warrant the exception status.

I changed the permission on the repo copy of the init script.  It was already
being installed with -m 0755 in the %install, the odd permissions were just a relic.

Changed Requires: smptdaemon to /usr/sbin/sendmail

New build currently in process.  2.6.1-4.fc7 is the tag.

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

_______________________________________________
Fedora-package-review mailing list
Fedora-package-review@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-package-review

[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]