Skip to content
This repository has been archived by the owner on Jul 4, 2023. It is now read-only.

Where do vendor variants of large stacks live? #21331

Closed
phs opened this issue Jul 19, 2013 · 6 comments
Closed

Where do vendor variants of large stacks live? #21331

phs opened this issue Jul 19, 2013 · 6 comments

Comments

@phs
Copy link
Contributor

phs commented Jul 19, 2013

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 generic vendors tap could be another way, letting contributors submit formulae that are maintained more collaboratively, similar to main-repo formulae.

@MikeMcQuaid
Copy link
Member

They should probably be in individual taps. I vendors tap seems somewhat reasonable but ideally you'd keep such things per-vendor I think.

@phs
Copy link
Contributor Author

phs commented Jul 19, 2013

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.

@phs
Copy link
Contributor Author

phs commented Jul 19, 2013

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.

@MikeMcQuaid
Copy link
Member

I don't think there's the demand for this stuff in the main repo.

@phs
Copy link
Contributor Author

phs commented Jul 19, 2013

How about the vendors tap? I agree that organizations who want to make their own official taps should do so, but for outside individual contributors (like me) it seems better than a one-off tap. My selfish motivations aside, a common vendors tap is more discoverable for casual users. That'll make formulae in it both easier to use and raise their general quality.

@adamv
Copy link
Contributor

adamv commented Jul 20, 2013

It should be an external tap; we don't want to service pull requests for these things, sorry.

@adamv adamv closed this as completed Jul 20, 2013
@Homebrew Homebrew locked and limited conversation to collaborators Feb 17, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants