mutt: awesomize the formula #20677
mutt: awesomize the formula #20677
Conversation
* Building from HEAD on Lion or greater requires autoconf, automake. * When built from HEAD, mutt tries to build the html docfile from source using docbook. If docbook and friends aren't installed properly on your system the doc build fails and you have no html docfile. So add a caveat (credit to @telemachus) that only HEAD-builders see explaining what happened and what to do about it.
* Separate option declarations wrt external patches from those dealing with mutt or brew options; sort them by name. * Remove overbearing baked-in configure flags (see [#20517], discussion of [#20516]) so that nearly as plain a mutt as can be builds by default ... * But allow a brewer to invoke all of them with one option, `--with-old-brewflags`. (Except for `--disable-warnings`, which mutt explicitly recommends not passing). * Remove dependencies associated with the removed flags. * Bring in almost all of mutt's configure flags as options. Leave them at their default values, except for NLS which is now disabled by default. (See comments in formula). * Add condtional dependencies for the new (and old) options that need them.
Don't bother building if the brewer requested header caching but didn't tell mutt which one to use. The build will fail anyway if there's no backend on the system. Tell the brewer what to do. Also, don't bother building if the brewer requested `--with-gnutls` but isn't building from HEAD. That build will fail anyway. Tell the brewer how to fix it.
The original formula knew well that mutt does NOT require a brewed ssl. It works fine with system's, even on Lion and up with their "deprecated" (but not broken) ssl's. That said, a brewer ought to be *allowed* to use a brewed ssl.
| exit 1 | ||
| end | ||
|
|
||
| depends_on 'gdbm' if build.include? 'with-gdbm' |
There was a problem hiding this comment.
You can do dependencies like this in one step:
depends_on 'gdbm' => :optionalThis will also automatically generate a --with-gdbm option, though you can still define the option if you want a custom description instead of the generic one.
|
Apologies in advance for crappy ruby or git (I know neither, and this is my first PR). Wrt the with/without/enable/disable prefixes, I think the brew options ought to match the prefixes of the mutt options exactly. I did that in this formula. @mistydemeo Thanks, I didn't know that. If it's all the same, I favor not using that construction because (a) the custom descriptions are useful, and (b) a great many of the options start with |
|
The descriptive option names are great - pairing |
|
I can't see how directly exposing all 40 or so upstream build options is an improvement. Part of the job of a package manager is to make some decisions on behalf of the user which options are appropriate for the respective environment. |
|
This is too much. It exponentially increases the number of variations of this formula that we ostensibly support. Users are free to customize formulae if they want this type of fine-grained control, of course, but we have to limit what we package to a reasonable size. |
|
@mistydemeo You're right, sorry. I got confused about what you were saying when I wrote that mini-reply. I'll do that. |
You can't see how not restricting mutt is an improvement?
Exactly. That's a good thing, isn't it? Are you thinking that this will become a bug-ticket monster? If so, why? And in what way could that not be solved with "go bother the mutt mailing list"? (If there were to be a build failure using some of the new options, it's a mutt problem, not a brew problem; the gnutls issue here is a case in point.)
I agree that part of "the job" is to not let users wreck the package with options that malfunction their environment. (That's why this formula will bail under certain user choices). I disagree heartily with the notion that part of "the job" is to force things on the user that would not be harmful to leave open to the user. Anyway, we've been through this in the threads cited: mutt is not a typical package. It is a poor choice for "let's keep it simple and make a 'generalist' formula. Making a simple and generalist formula is usually the right way to go, but not in this case IMHO. I will look for some of the more esoteric options and comment them out. |
|
Ok, I guess I'll just be blunt: we're not going to have formulae with 45 options in core. |
You don't need to be blunt. I could see that's what you meant :) (My post was asking: "yes, but why not?") I suppose this settles the question of whether mutt should be farmed out into its own tap?
|
Taps are of course free to do whatever they wish.
I'm not saying this is an all or nothing situation, just that the current proposal is too much for core; a reasonable subset of these options is fine. For example: None of Anything that (a) doesn't add a dependency and (b) doesn't disable functionality should just be on by default. Things that have a "with" and "without" variant need to pick one and handle the other one implicitly. |
Yes, but my sense was that the new mutt tap was supposed to be either "official", like homebrew/science, or at least semi-official like samueljohn/python. If so, I'm sure the policy isn't "anything goes", so I was just checking. BTW, if the mutt tap is going to be (semi)official, what's the procedure for getting the ball rolling? Of the options in your list, @jacknagel, I already commented all of them out (just haven't pushed yet).
That's how it is already, with the notable exception of the header-cache backends. There is a comment in the formula that explains why both 'with' and 'without' are made explicit. |
Per the advice of @mistydemeo.
|
@mistydemeo OK, I've taken your advice. Some 'with' options aren't amenable to that treatment though. bdb, libidn, and tokyo-cabinet are such that the brew package name doesn't match the suffix of the mutt-option name. |
Some of these will return in a tapped version.
NLS is off by default, so the only thing needed, brew-wise, is `--enable-nls`.
So only people who manually built it could benefit from this option.
That isn't really important, just use the brew package name for the user-facing option. Dependencies that are made conditional with language level conditionals (i.e. |
|
OK, now we're down to 25 non-patching options (I count all the hcache backend related ones as four, one per backend). |
|
As far as how |
This requires departing from the real names of the mutt options. I don't like this, but apparently the alternative is worse.
|
So can If so, I will change the tokyocabinet one to read: If not, I have no idea what to do except leave them as |
|
Just wanted to chime in and say I agree with @jacknagel here in terms of options; enable everything that doesn't add dependencies, enable some things that add dependencies but are required to be useful and make the options stick to patches and cache backend selection. |
|
@MikeMcQuaid, @jacknagel Just to clarify: Do you not want even options to turn off some features that most people will want, but some won't? It seems reasonable to me to include extra options (even many of them) for that case. (I'm thinking of people who won't want imap, pop, etc. --- who want mutt only as a mua.) The extra options shouldn't normally bother users who simply install as-is, though I suppose they would show up on the output for In any case, if that kind of "turn everything off" options aren't allowed, then I do think there will need to be a mutt tap alternative in order to give users like @chdiza and @tlvince what they want. I don't necessarily think a mutt-lite tap would be a big deal or a bad thing. I'm just trying to get clear on what is likely to be pulled into master. (To be honest, I never expected this version to be included in master. I can see that it has a very different approach from Homebrew's normal way of doing things.) |
|
What does turning off these features give you? Faster compilation? Faster mutt? |
Well, it does give faster compilation. But (to me) it is a means of avoiding build problems that stem from having those things enabled, when building from HEAD. Building from HEAD is the most sensible thing to do IMO, for reasons explained here and in the other threads. |
@MikeMcQuaid, what about options for using gnutls instead of openssl? What about enabling gpgme? What about libidn? These are not needed in order to be useful to most users, but essential to some. There are already, in the official formula, other options like this (namely slang and enable-debug). |
If it's dramatic I think there's an argument to be made.
If you care about the latest features, yes. If you just want a mutt that works, probably not. Sounds like the solution is to put a
I'm OK with dependency-pulling things being dependencies. That said, it is worth asking what adding/removing these dependencies gets us. Configurability for its own sake has little virtue. |
|
@MikeMcQuaid You seem to be giving arguments that work against including HEAD in any formula whatsoever that has a stable version. Why does Mutt has a stable version, so I don't know why it would go in headonly.
They get you gnutls, or the ability to have internationalized domain names, or the ability to encrypt and read encrypted email. True, not everyone wants or need this, but exactly the same thing holds for slang. (I can't see why anyone would want that unless they're using a weird terminal). |
|
I don't have a problem with having HEAD in formulae. I have a problem with making formulae messy because HEAD builds sometimes break compilation.
This is the type of thing I'm talking about. gnutls is a library, it is not a feature. To extend what I said earlier: if dependencies enable an important feature they should be |
That is a spurious distinction. The feature is that mutt will use gnutls instead of openssl when making connections. Doing so is necessary, or at least a big improvement, for some people due to the particular email servers they have to deal with. If using gnutls rather than openssl libraries made no difference to anything, it would not be a mutt option. I happen to agree that openssl should be primary here, if for no other reason than that brewing gnutls requires brewing ten billion other things. |
|
It's a matter of support. With the current Homebrew model we can't support the inevitable breakage that all these options will cause in months to come. It's not your fault that these things will break, it just happens. What we need is a way to have you maintain the formula and get the bug reports that are associated with it, as you clearly are keen to have the mutt formula support these options, and know and understand mutt well, you are perfect for this role. Since Github doesn't allow us to give users access to individual files in the repo, we can't do that this way. We need a mechanism for having formula be in taps more easily, then the Homebrew collaborators can say: ok, this formula can be from this tap as a default. Then the update logic is still fast somehow, perhaps via brew bot copying updates into mxcl/master from the other taps. Anyway, in short: we love your work, and our issues are simply support, you can imagine how vast homebrew's support burden is currently, until we can shrink that, we are being stubborn, unpleasant, and typical open-source arseholes. Sorry. |
|
Very well then. Is there anything in the new version of the formula that should be kept? I must say I'm shocked at the resistance to including HEAD. Including HEAD in pretty much any formula whatsoever will sometimes break compliation for that formula. But whatever, I'm done fighting for that. However, there seems to be support for allowing the header-cache backend to be optional. (I must say I'm shocked at this too; I figured that's where most of the resistance would be centered). How about the In short, shall I abandon this entirely and leave an awesomized formula to a tap? Or shall I keep some small set of changes and have this pulled in? |
|
I'm not opposed to HEAD, just to adding options that only provide a benefit to HEAD builds. |
OK, there were only ever really three options that provided any HEAD-specific benefits at all, all added in the penultimate commit, and all of them serve only to disable things on by default: imap, pop, ssl. These options reduce complexity and potential tickets, because they turn off potential ticket-generators. Indeed, the only specifically HEAD-related benefits of these is to avoid compilation and configuration failure. But these and the rest of the "turn off the defaults of the official formula" options appear to have been nixed on independent grounds. So there shouldn't be any opposition to HEAD at all, not even conditional opposition. (There were, however, two dependencies that only make sense from a HEAD built: autoconf and automake on Lion and up. Those seem perfectly acceptable though.) |
|
Ping: I'm not sure where we are currently. If someone writes up a formula that adds HEAD to mutt, would that be useful? (I'm assuming no tweaking any of the options, except for maybe removing the unrecognized |
|
Yes, that would be. |
|
Nginix similarly has a large number of user specific options, and we delegate handling that to an external repo: https://github.com/marcqualie/homebrew-nginx Suggesting that an interested party move the "full featured" mutt formula to an external tap as well, and maintain it. |
|
Closing this with my suggestion above, that a mutt repo could be maintained similar to the nginx one, that had a more extensive set of options, but was handled outside of Homebrew itself. |
|
@chdiza If you've got a version of your formula for 1.5.22, I wouldn't mind trying to maintain a tap for it. |
|
@gthank I keep a tapped mutt formula myself for convenience (https://github.com/telemachus/brew/blob/master/Formula/mutt.rb). The upgrade to 1.5.22 mainly meant that one patch no longer applies cleanly and some others needed new URLs. See here for which patch I had to remove, the new URLs and the new SHA1. Hope this helps. |
|
Unrelated comment: if you're duplicating things from core in a tap I recommend renaming to something like |
|
@MikeMcQuaid Yeah, I suppose. But I don't mind installing it as |
|
I'm not sure. |
This PR makes the mutt formula awesome. See [#20517] and [#20516] and
the discussions in the latter. To wit:
dependencies conditional where needed.
--with-brewed-ssl.I didn't squash yet, so that the diffs would be readable.
Thanks to @telemachus for help and suggestions.