-
-
Notifications
You must be signed in to change notification settings - Fork 11.4k
Where do vendor variants of large stacks live? #21331
Comments
They should probably be in individual taps. I |
Individual taps seem to invite orphan ware: once I ride off into the sunset, the only way for the next guy to update the URL is to make his own fork. That sucks. |
What about name-munging the vendor onto the package name, and submitting them into the main repo? I personally don't see much utility in explicitly acknowledging or modeling the variant-vanilla relationship; it doesn't seem to get you anything over a pile of similar packages with similar names. For example, the release cycles for the vanilla and variant flavors are already strongly divorced. |
I don't think there's the demand for this stuff in the main repo. |
How about the |
It should be an external tap; we don't want to service pull requests for these things, sorry. |
I have a mighty need to use cloudera's hadoop stack. I'm also pretty sure I could write the formulae.
What I don't know is where I should submit them to stay kosher. This has been tried before by other folks without much success.
It appears that part of the problem is homebrew doesn't have a policy for vendor variants, which for large projects can be substantially different than their vanilla equivalents. In this case it isn't really just a past version, since the variant actually contains functionality not in the original (incidentally, this is why I'm using it.)
What should I do?
The
versions
tap might be a somewhat sane place to keep it. Alternately, if I owned cloudera's github org, I would just write my tap there and be done. I don't, nor am I interested in becoming the primary maintainer of what could be a widely-used tap. A genericvendors
tap could be another way, letting contributors submit formulae that are maintained more collaboratively, similar to main-repo formulae.The text was updated successfully, but these errors were encountered: