man-db 2.8.2 & libpipeline 1.5.0 (new formulas) #25376
Conversation
Have any of these patches been submitted and accepted by their upstreams? |
I'd suggest hosting them your own tap for now and work on getting the respective upstreams to accept the patches. Thanks for the PR nonetheless! |
|
@commitay Sigh... I was afraid that would happen. Sadly, this effort was made two years ago and has tried to be revived since then. You simply cannot get some projects to accept patches sometimes, especially when they are not intended for OS X. I have counted at least 283 formulas in Homebrew right now that use a patch to fix problems. I do not see why these programs would make such a difference. |
If upstream has no intention of accepting the patches we would be carrying them indefinitely and making ourselves "upstream". |
|
@commitay Well, then I guess we're the upstream for almost 300 packages right now ;) For reference, here is the specific thread where things petered off. Unfortunately, these kinds of projects usually don't respond much to changes like this or bugs on OS X. E.g., inetutils would not fix some issues with |
|
Here is my tap, for anyone who is interested. |
|
@ylluminarious I think it's time to move such efforts to MacPorts. There are a lot of troubling things going on in Homebrew and I'm personally moving away. It's just not the project it used to be and not what I'm looking for in managing this area of my OS experience anymore. |
|
@ylluminate such comments, especially without elaboration, are useless, discouraging – and frankly obnoxious – feedback. |
|
@ylluminate We have had this patching policy for years and years at this point so this isn't some recent change. Homebrew has reached a size relative to maintainers and other resources where we've needed to narrow down what we attempt to support and our metrics show a decrease in failed builds in official taps as a result. In short, Homebrew is getting better and more stable for the most common cases. If that's not you: yes, please go and use MacPorts instead but, as @ilovezfs mentioned, refrain from telling us about it. You are not contributing to Homebrew (unlike @ylluminarious) so it makes no difference to us what package manager is the best fit for your personal needs. @ylluminarious Thanks for creating a tap. That's the best way of supporting the longer-tail of packages that aren't a good fit for Homebrew/homebrew-core ❤️. |
|
Well here's my problem guys. And I apologize, I was not wanting to add this to this thread with the risk of having this locked, but I'll share some thoughts. Homebrew has become more and more conservative with regards to the packages it absorbs into the maintained taps. I understand the logic behind your desire to have both quality and non-problematic packages for consumption, but that is not actually what is generally desired when one goes to a package manager like Homebrew. A package manager, such as Homebrew or MacPorts or Fink, serves two general purposes: 1) find and use packages and 2) setup workstations (fresh or re install). I have been worried about Homebrew for some time now about it's role in these domains. I realize that quality (control) could be considered a high priority, but at the end of the day it's a secondary priority to the actual needs of the community that uses it and defined it's need in the first place. Homebrew was originally attractive due to A) it's large package base and B) it's easily accessible or modify-able recipe / forumla system built with Ruby. As the years of have progressed B has evolved to become the only real profit of Homebrew. This is unfortunate and has created a problem for many would-be users and old users who once saw value in Homebrew. People are generally feeling this, but I don't think many have really tried to make the argument because they have felt the sting of reprimand in experiences such as this one. To be frank, the Homebrew community is seen (by those who are truly interested in it and have differing perspectives) as being or becoming a hostile non-safe place for opinions and the # 1 non-stated actual goal of users above. Argue as you may with this, but this is reality and I hope that it shakes a little fruit loose, but I doubt that it will from my discussions with other Homebrew users and those who used to use Homebrew. There are a lot more disenfranchised Homebrew refugees than you want to believe exist. I wish it weren't true and I wish that people didn't feel attacked and the need to rehome their package manager needs, but it's a fact that is going to catch up to Homebrew sooner or later. At the end of the day finding obscure, but needed, packages is a super critical part of the goal of finding and using packages. No one, I repeat, NO ONE, wants to manage their own taps or make their own formulae or hunt for previously existent ones or obscure ones floating in the void of the Net. If given the choice you'll get the same result 99.9% of the time, people want a quick and efficient usable solution (having it high quality would be nice, but "workable" is the key because a lot of times it's not a long term solution that's being sought but rather something that they can use to solve an immediate problem and then maybe even forget). Many are seeing threads now about software that used to be available on Homebrew, but now isn't available. People are trying to make them work; pulling old archived commits, and doing all kinds of voodoo that they really don't actually want to do. This is disheartening and strongly discourages fealty to Homebrew. |
As we did ask: thanks for spelling them out with a considerate tone and apologising, we genuinely appreciate it ❤️.
I don't agree with this. We are not adding many more requirements for formulae but just being more consistent on the requirements that at least some maintainers (e.g. me in the case of patching) have had almost since Homebrew began.
Also, as I was interested in crunching the numbers, they don't actually bear this out. Looking back onto the number of packages in Homebrew/homebrew-core (or Homebrew/homebrew or mxcl/homebrew when they were things) on the same date in previous years we don't see some dramatic slowing down: 2018: 4489
Different users desire certain things. I'm not going to pretend that all users want a smaller selection of high-quality software but that's what the maintainers want (because it reduces our support burden and because we care about quality) and ultimately we're the ones who keep the show on the road.
I'm afraid I disagree strongly. The direction of Homebrew is decided primarily by the people who contribute the most to Homebrew. In the case of Homebrew/homebrew-core: that's @ilovezfs (which is why they are the lead maintainer of this tap). Thankfully all the Homebrew maintainers care about the community and not just the packages we personally use or the code we find fun to work on but, as mentioned above, our priorities will not align with all of those in the community. The early adopters who would rather we had way more packages and don't really mind if things are broken may find another package manager is a better fit for them now. We aim to cater for the people who expect
I think the Homebrew maintainers (myself included) are increasingly unwilling to put up with rudeness, negativity and drive-by opinions on our issue tracker (which is meant for tracking issues and not random conversations), forum (which is meant for users to help each other with Homebrew problems) and social media (because if you don't have something nice to say: don't @mention me or Homebrew with it). When you've literally got people around the internet insulting you, your family, threatening to sue you, threatening to attend conferences you're at in a professional capacity to disrupt them and reporting you to your employer to attempt to get you fired: your tolerance drops somewhat. We're not going after those people who want to write negative blog posts about Homebrew but if you're in our back yard I'm afraid you need to go by our rules.
If no-one wants to manage taps or make their own formulae, diplomatically, why do you expect the Homebrew maintainers to do this for you?
The problem is: when it doesn't work it becomes Homebrew's problem and not the person who originally submitted the PR.
Again, given the numbers above I can't see the evidence for this. If this is expanded more generally to taps in the Homebrew organisation which have been archived: we screwed up in accepting these in the first place. We've tried to be publicly relatively diplomatic but these have been a massive issue for the Homebrew maintainers in terms of issues, quality control, security, support and, particularly, the impact they've had on our CI infrastructure. A bunch of them were literally unmaintained when they were archived. This has been painful for the community, the maintainers and the taps but once we get through it we'll be in a better place moving forward in terms of expectations. |
|
@MikeMcQuaid @ilovezfs I appreciate the work that's been done on Homebrew. It's a nice system for managing things on OS X specifically, although I also see value in Macports and Fink which provide experiences similar to other Unices like FreeBSD and Linux (respectively). In fact, I find Homebrew so nice that I am willing to go to the trouble of maintaining and using my own taps, although I agree that things would be better if this were not so prevalent. @ylluminate had no intention of being obnoxious or otherwise unpleasant. I understand that his initial comment on this thread may be perceived as such, but I would like to further clarify some of his points and add my own points as well in order to prevent such sentiment and any proverbial bad blood. I will go about this by responding to some points made by both @MikeMcQuaid and @ylluminate in chronological order. In response to @MikeMcQuaid's initial comment on this thread:
I think the point was that it does make a difference what dissatisfied or disenfranchised users say. Contributors are not the primary users of a piece of software. Saying "you're not contributing so it makes no difference if you like our software or not" is a good way to lose or turn off users. I've seen it myself plenty of times and I've felt the same on occasion. I'm not trying to shame anyone here; just trying to clarify what was meant. It is sometimes difficult to understand someone's intent behind a piece of text.
You're welcome. In response to @ylluminate's second comment on this thread:
I agree with this. Especially that a package manager is used to find software. Homebrew is essentially a frontend for compiling stuff on your own (although the same could be said of Macports, Portage, etc.). So removing packages or rejecting packages that would otherwise work fine, based simply on aesthetics, is kind of mean to users. You're giving them no alternative than to compile the software on their own, as well as any updates. And that, let me assure you, is a pain in the neck. The second point made here will be addressed in my following remarks.
In light of @MikeMcQuaid's data in the next comment, it seems that this point is rendered invalid. This is not so. This seems like a non-sequitur at first glance, but let me assure you that it is not. You see, Homebrew was perceived to have a large package base at its beginning. Not its very beginning, but in the earlier years wherein it started to pick up steam. People expected to find their favorite programs and be able to To give some examples, I'll start with the fact that Homebrew does not provide a very straightforward way to install a specific version of a package. The best way to do it is to do Furthermore, Homebrew does not support root access at all. To do it requires modification of Moreover, Homebrew does not quite support installing to places outside of Yet another concern, and perhaps most worrisome of them all, is the fact that the Homebrew maintainers are sometimes rather restrictive in letting other people disagree with them. I understand that threads which go completely off the deep end need to be locked and sometimes there really are offensive things that no one wants to hear. Nonetheless, censorship is a dangerous game and people which get too used to the ban-hammer start to become too ready to use it. Some examples that I can think of off the top of my head exist here and here and even here. The first thread even had one of its comments deleted before it got locked. It is really a shame that such threads get deleted or locked since such an act usually halts all progress on fixing the bug for a very long time. Users usually look under a project's "Issues" or "Bugs" page in order to find the bugs that they're experiencing. Finding out that a maintainer banned further discussion of the issue is a troubling sight and is discouraging to many users. Maybe not the majority of users, but certainly enough to matter. I truly think it's unfortunate to see comments like "I don't like your tone" as justification to ban a conversation. Especially when users are just frustrated that maintainers refuse to meet their needs because they don't like a 3rd-party developer's decision. As a person who has dealt with actually abusive people, I know that shutting someone up because you don't "like their tone" is not a valid reason. It is also quite unkind and it often shows a person's insecurities despite their attempt to appear superior. Now, I again am not trying to shame anyone, but as an objective Homebrew user who has an interest in the project's well-being, I am merely trying to help improve the atmosphere to provide the most productive situation.
Yes, this is unfortunately true. There are more disgruntled Homebrew users who are uncomfortable voicing this fact within earshot of the project than some people realize. It is largely due to the reasons which I enumerated above and others like it. But it largely is because of the general attitude of just forgetting about some users.
This is a bit subjective but I do know that some people use package managers in such a way. What needs to happen is a balance to be struck between quality-control and permissiveness. It can be done with the right attitude.
This is also unfortunately true. Some such people do try and contribute fixes to Homebrew, but the majority of users who feel such a sentiment often either move to another package manager, or worse, they stew in their juices and feel like Homebrew is stepping on their toes for no good reason. It may not happen to an awful lot of people, but it does happen. In response to @MikeMcQuaid's second comment on this thread:
Thank you for giving a genuine response in turn. I hope this will remain a civil discussion and that no censorship will take place. Disagreements can be important for a community to grow and improve.
An understandable viewpoint. However, I might suggest that being more consistent with the requirements on formulas is not really different than being more conservative. These requirements are not always important, as in the case of my tap. I believe that sometimes these requirements exist out of aesthetic opinion, not really that a certain piece of code in a formula will cause a problem.
I already addressed most of my thoughts on this in my above remarks on @ylluminate's second comment.
Well, I would argue that the users keep the show on the road. Without people using Homebrew, the maintainers would quit maintaining it. I'm not saying that this will happen, but it is possible to see a gradual drop in the actual number of Homebrew users over the years if the current trend being discussed continues. Nonetheless, I have never agreed with the sentiment that a piece of software is better when the developer pursues his own desires for it than what the users need. I, again, think that a balance needs to be struck here. Because, while I respect the fact that a piece of software like this can be difficult to maintain, I also think that users need to not feel like they're not welcome or that their use-cases are not welcome.
Again, I think this is a fundamental philosophical difference in the way people think a project should be run. I do believe that having a balance between these two seeming opposites would benefit everyone involved.
I think those of us in this thread understand and respect that. None of us have @-mentioned you and @ylluminate's initial comment was not a "drive-by" opinion. It was merely a suggestion out of frustration that was caused by the proverbial straw that broke the camel's back. I think that Macports and Homebrew have value and I am interested in seeing which one better suits my needs. Or perhaps, they both cater to different needs. Not to imply that I am severing ties with either.
I think we all also understand this sentiment as well. No one is insulting any maintainer's family, threatening in any capacity, or reporting anyone. Moreover, no one here is writing negative blog posts about Homebrew and we are doing our best to abide by the rules of this "back yard" while still trying to have some free discourse of opinion and constructive disagreement.
That is the point. No one is expecting Homebrew maintainers to do anything. They are volunteer workers and I think everyone respects that in some capacity. We are simply hoping that they will be more lenient in letting more packages into the project.
I think that if the person who submitted the PR goes MIA, Homebrew has a right to simply let the formula stagnate if it's too difficult to fix. However, that does not necessitate deletion of the formula or for it to be a problem to the maintainers. If a user has a genuine problem, let them file a ticket. If it's unpopular but some people have installed the formula, there is no reason to delete it. Just let it exist and forget about it if it's too much trouble. Otherwise, you're marginalizing users of Homebrew who may never work up the initiative or ability to go and change the formula to Homebrew's strict test suite's satisfaction.
Yes, the taps that have been removed is also another concern. I understand why it was done, but it is a bit troubling to find solutions which rely on these taps which you now have to manually install and roll back in order to get some needed functionality. I think that these taps could have been fixed up to a point that they were sufficient without having to have been archived and declared dead. Again, I understand the headache of maintainership, but it is still an unfortunate situation to which I think there was a better solution. In any case, I understand that some of these concerns will not be addressed, but nonetheless I think it is important to bring them to light and hopefully also provide a better understanding of the situation here so that no false implications are believed. I hate to see divisiveness reign because of misunderstanding. |
Again it's worth asking: why should the Homebrew maintainers maintain a tap/formulae for you if they do not wish to do so?
My point in turn is that listening to dissatisfied or disenfranchised users on GitHub or Discourse is not the primary mechanism for deciding the Homebrew roadmap. We're trying to build a particular tool in a particular way and that results in us making some decisions that will knowingly alienate some users. Homebrew cannot be all things to all people.
Non-contributing users do not contribute (no pun intended) to the sustainability of the project. No contributors or maintainers? No project for any of the users.
This is a notable change: Homebrew is now a primarily binary package delivery mechanism and was previously a from-source package manager. We're moving from Portage to Apt. Again, this points to the above where we're likely to knowingly alienate some users in the process but we're happy that they have MacPorts or Fink or Portage that they can use instead.
It's never based on aesthetics. It's based on our experience on what's required to maintain and support a package sustainably over time. In this specific example: patches are bad because they break functionality and the patches themselves bit-rot over time. If upstream won't accept them: it's a ticking time bomb waiting to happen.
We'll agree to disagree. I regularly hear the opposite from users. I suspect this depends on whether you're coming from a Linux package manager or not. Yes, we may well have less of an overlap with Apt but we package a bunch of newer and niche tools that they do not.
No-one is being crapped on to the same extent as the maintainers who are being abused publicly and privately, sorry. Ultimately the majority of Homebrew/brew development is done by me and the majority of Homebrew/homebrew-core development is done by @ilovezfs. No-one can compel us on how we spend our free time working on Homebrew and if I don't see a value in a particular feature I won't work on it. If I think it's actively harmful: I won't review or accept a PR with it.
We used to provide I'm open to a PR that makes it easier to add versioned packages into your own tap but we're never going to support arbitrary installation of every version of every package, sorry.
Homebrew upgrades it for you because otherwise we have to support every package against every combination of every recursive dependency. This is not scalable.
We used to, I made pretty clear what was required for it to continue (someone implement it so it would drop privileges during compilation because the sandbox doesn't work), no-one did so we didn't. This was based on real, major security implications.
You can have a
That's because we build our bottles for there and we don't wish to support configurations that can't accept our bottles. See also: we don't support old macOS versions.
We seem to be allowing it here. To be more exact: we're restrictive in allowing off-topic, abusive or endless bike-shedding on our issue tracker (and, less so, Discourse). You can express your views on Homebrew however you like anywhere on the internet (although if you @mention rude things to me/MacHomebrew on Twitter: expect to be blocked).
We routinely lock old threads that get noisy. We've done this for a long time and I wrote a tool for this and then a GitHub feature as the alternative is the maintainers drown in email repeating the same comments or questions repeatedly.
It's not censorship to say you're not allowed to say whatever you want in any space. GitHub and the Homebrew issue tracker are not a public discussion forum. Can I come into your house at 4am with a group of my friends and have a loud discussion about Scottish politics? No? Is this censorship? No because I can go almost anywhere else to do this.
This is not the case. Bug fixing happens in pull requests and not issue comments.
We intentionally close bugs that are known bugs that we don't plan on fixing so this doesn't apply to our project.
I think it's unfortunate that people cannot ask politely for additional free time to be spent by volunteers and moreso that they cannot see that their inability to ask politely means their issue is unlikely to be ever fixed by said volunteers.
Please let's not make assumptions on what I and other maintainers have and haven't dealt with. Suffice to say I've dealt with more than my fair share of in-person physical and verbal abuse and online verbal abuse.
As this is a small aside in otherwise a politely worded comment I'll let it slide but to be clear here: you are calling me and/or other Homebrew maintainers insecure and acting superior here. Either that was not your intent or you should come out and say what you actually mean.
I'm glad it's out of earshot, we don't want to hear it, thanks. Again as mentioned above: we're not forgetting about some users: we're intentionally making decisions that will make some users happier and some users more frustrated with Homebrew.
We agree and we are doing this. You just disagree where this balance should be struck. That's within your rights but clearly it's going to be ultimately decided by those doing the most work on Homebrew.
Again: it's not censorship to lock threads. The inability of many to have a civil discussion is why threads are locked.
Yet our analytics show the numbers keep increasing rather than decreasing. Again, data contradicts anecdote, here.
Some use-cases are not welcome.
I'm afraid it was. It should have been a private comment in some other communication medium. There's nothing that relates it to the content of this pull request and it was directed to you and not the maintainers.
These contradict, though, because the Homebrew maintainers wish to maintain the packages they allow into the project which requires work from them.
I'll end with this: I'm afraid, no, you don't understand what it's like to maintain a project at Homebrew's scale for 8 years and there's very few people in the world that do. This post and this talk may give you a little bit more of a sense. Thankfully I am in contact with some of these people for help and mentorship and I continue to learn and evolve as does the project. That said the main point I want to repeat from above: we know that all decisions we make will make some users happy and some disappointed and this is deliberate. Homebrew would rather have every |
brew install --build-from-source <formula>, where<formula>is the name of the formula you're submitting?brew audit --strict <formula>(after doingbrew install <formula>)?man-dbis the man page system for Linux. It is more featureful than OS X's built-inmancommand (which is derived from an old version of BSD). It is quite useful for developers and system administrators and some useful software plugins rely on Linux'smanbehavior, which has not been available on OS X hitherto.man-dbdepends on a library calledlibpipelinewhich is also included in this PR. Unfortunately, both of these programs expect to be on a Linux system rather exclusively. So, some patches and extra compilation options are necessary in order to get these programs to work right. I hope that these formulas will make it into the trunk; they are very useful and it will be very nice to have Homebrew take care of these packages instead of manually compiling updates by hand.