I think we're agreeing loudly - as I said, I have concerns about the implications of allowing it to be configurable, but if we did, we should probably blacklist overriding any hardcoded defines.
Not allowing that also resolves that problem. - Rich On Mon, Mar 25, 2019 at 10:08 PM Josh Paetzel <[email protected]> wrote: > > > > On Mon, Mar 25, 2019, at 6:32 PM, Rich wrote: > > I'm not usually in favor of limiting configurability, but in this > > case, I agree with Joshua - letting people add their own custom > > defines for e.g. debian-buster or epel6 or ubuntu1604 might be fine > > (though at that point I'd still like something like a constraint > > solver to say "I want this to work on platforms X, Y, and Z" and have > > it DTRT, but if nobody else agrees that's probably overkill :P), but > > probably not a good plan to allow overriding portable{,-[0-9]+}, lest > > people be allowed to override what the consistent names mean and > > defeat the purpose. > > > > (I'm also torn because I somewhat feel like allowing overriding a > > subset of symbols might result in the same kind of problem, where e.g. > > every distro using ZoL 0.8 de facto ships a set of additional defines, > > but installing from source or running on e.g. illumos could result in > > inconsistent outcomes. But it's unclear how academic this fear is, and > > having some of the functionality is probably strictly better...) > > > > By allowing a custom define you've now also added responsibility for having > that define available on every system that imports the pool. Which even if > you skate around the whole "this random system doesn't have the define used > to create the pool" and embed the define in the pool itself you have to > handle conflicts (what if the system already has a pool imported that has > defined that value differently?) > > You quickly devolve to the moral equivalent of: "let's have a text file that > contains every IP and hostname on the internet and just ship that around. If > a host doesn't have the most recent version of hosts.txt then it won't work > correctly sometimes but that will be rare." :) > > "No no, you're exaggerating, it's not like that at all." > > I'd like to call the ball on this and say "Not for version 1.0. We are just > trying to improve what we have right now incrementally." > > I'm not saying the request is without merit or value. We should tackle it at > some point. However doing this right needs a little seat time, which I think > we can get with data pools. > > -- > > Thanks, > > Josh Paetzel ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/Td66d70a086ae5a9e-Mef8205c53af5fc938127c3d8 Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
