https://bugzilla.redhat.com/show_bug.cgi?id=1485458 --- Comment #17 from Jonathan Dieter <jdieter@xxxxxxxxx> --- 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. > (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. > > > 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. > 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. -- 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
