https://bugzilla.redhat.com/show_bug.cgi?id=1485458 --- Comment #18 from Martin Brandenburg <martin@xxxxxxxxxxxxxxxxxxxxx> --- (In reply to Jonathan Dieter from comment #17) > I've trimmed a lot from my reply. Anything trimmed looks great! > > (In reply to Martin Brandenburg from comment #16) > > (In reply to Jonathan Dieter from comment #13) > > > FWIW, if I was going to deploy OrangeFS where I work, at least one of the > > > security modes would have to work for me. > > > > Quite. > > > > The advice I got from rdieter in #fedora-devel is to compile is three > > times within the specfile and then use subpackages. > > > > If there's no better solution, I may just declare it out of scope for > > this package and that if we want it, we'll have to make security a > > run-time option rather than a compile-time option. > > > > Rex's (and, since I'm sure you wondered, no we're not related) final advice > to focus on one first was good, so I think declaring it out of scope until > you guys have made security a run-time option is the best option here. > > > > The reason I prefer putting nonfunctioning config files straight into the > > > right locations is that, as a user, that's the first place I look when I > > > want to configure them. Copying the example config files from > > > /usr/share/doc/ is an extra step. I would recommend commenting out the line > > > in /etc/pvfs2tab with a comment above it briefly explaining the correct way > > > to configure it or at least pointing to a man page (see /etc/fstab for an > > > example of the kind of comment I'm looking for). > > > > Sounds good. For the server config, shall I put in a DeleteMe option > > that the server will throw a syntax error on? Well even without, the > > server will throw an error on the missing storage space, and the user > > will have to read the documentation or at least look in the config file > > to learn how to create it. > > If the server will throw an error anyway, I wouldn't bother with a DeleteMe > option. > > > > > > * pvfs2-{start,stop}-all should be %config as they need editing? > > > > > > > > They're also in /usr/sbin. Putting them somewhere as an example or > > > > extending them to take command line arguments may make more sense. > > > > > > If they require editing, you can't leave them in /usr/sbin as is. I'd mark > > > them as documentation. > > > > Right. I could move them to /usr/share/doc/orangefs, but I don't see > > where they require editing. > > I looked through them and it seems that they *can* be edited. If upstream > *recommends* editing the scripts directly, then they should probably go in > /usr/share/doc/orangefs, otherwise you can probably leave them where they're > at. It looks to me like they accept command line options, but can be edited to code in specific defaults. They also don't use systemd. As a sysadmin, I'd rather have systemd start the daemon at boot on any machine I wish to run it on. I don't see any reference to them at all in any of our documentation. So I think the conclusion is that I'll move them to /usr/share/doc/orangefs if I don't drop them entirely. While we're on the subject there's some docs I should build and install there. > > (In reply to Dave Love from comment #14) > > > You can at least conditionalize it so that you can build most of > > > orangefs on those platforms. I think I tested that. > > > > Jonathan, what do you think? The options are to drop support for > > aarch64 entirely since part of it will be missing or build what will > > work. > > I'd probably prefer to build what will work, but conditionalize it so the > missing stuff is only missing on aarch64. I'll do that then. I'd certainly prefer to run on more systems than less. > > > > There's some argument here that we should not package Karma, because it > > > > may not work. > > > > > > I had a note that it had been replaced by grafana support, which I > > > assume I got from the list, but it sounds as if that's wrong. > > > > I had the same note. I don't think it's readily available. > > Including karma isn't a blocker for me. If it's not supported, we probably > shouldn't build it. On the other hand, if the alternative isn't actually > available, that kind of sucks. You go ahead and make the call. I think I'll drop that. > > Git: https://github.com/omnibond/orangefs-fedora > > Koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=22006250 > > Spec: http://dev.orangefs.org/2017/marbran/1002/orangefs.spec > > SRPM: > > http://dev.orangefs.org/2017/marbran/1002/orangefs-2.9.6-0.3.20171002.svn. > > fc26.src.rpm > > The SRPM link gives me a 404. Looks like I typed an extra dot. Try http://dev.orangefs.org/2017/marbran/1002/orangefs-2.9.6-0.3.20171002svn.fc26.src.rpm -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx
