On Tue, Sep 23, 2014 at 01:55:09PM -0400, Kay Sievers wrote: > ----- Original Message ----- > > > We are not applying this patch now. It introduces a complete new > > > scheme and we do not want to extend the current SCSI code, we only > > > fix obvious bugs. > > > > Fine with me, however not sure what our story should be for years to come > > regarding SCSI stuff downstream. > > Simple as: Don't add new features to systemd/udev, only fix bugs. > > SCSI code needs to be maintained by someone who understands it and is > capable and willing to maintain it in the long run. Systemd/udev > maintainers lack the experience and cannot do that. > > New features need to happen in an existing or new storage related-package > and not in the systemd/udev code base.
Systemd+udev are supposed to be about providing a fairly complete basic environment. I don't see why an exception should be made for SAS disks. If necessary, we can bring additional people in, or maybe just wait for patches. This seems like a better solution than waiting for a project to be created to create and maintain a tiny amount of code and one line of udev rules. I think that the failure mode is especially ugly here: if you have the hardware, but don't install this mythical extra package, systemd/udev provides one set of "stable" names. Then you install the extra package, and you get a different set. > > Kay, any serious objections to applying only > > downstream for RHEL? > > Well, the currently created links will go away and potentially break > existing users. Not sure what is acceptable here. I personally would > not apply it to any released product. Right, so applying the patch as is is probably not OK. But we could provide the old names as an additional alias. This should be doable. Zbyszek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
