https://github.com/mxcl/homebrew/commit/ce3cc386b678de320074c864791ab4a09599faa5#commitcomment-185939 I've reverted the unofficial binary added to this package. I don't think we should ever accept binaries from anyone except very reputable sources (e.g. the upstream project) and, arguably, shouldn't accept binaries unless the build process is very difficult (which matches this case). Hope this doesn't step on anyone's toes, I just think it's a big enough issue to warrant discussion. I'm getting concerned about the potential security issues of our contribution model combined with binaries and upstream patching. One serious security exploit could seriously decimate our user base. Then again, I'm naturally a bit paranoid about this stuff. -- Cheers, Mike McQuaid http://mikemcquaid.com
I rewrote the formula for sbcl 1.0.43 as part of my induction period contribution. Please see https://github.com/tianyicui/homebrew/commit/ec6815f86dd716a86936188416e5fe4004ec8e11 . On Fri, Nov 5, 2010 at 6:10 PM, Mike McQuaid <mike@mikemcquaid.com> wrote: > > https://github.com/mxcl/homebrew/commit/ce3cc386b678de320074c864791ab4a09599faa5#commitcomment-185939 > > I've reverted the unofficial binary added to this package. > > I don't think we should ever accept binaries from anyone except very > reputable sources (e.g. the upstream project) and, arguably, shouldn't > accept binaries unless the build process is very difficult (which matches > this case). > > Hope this doesn't step on anyone's toes, I just think it's a big enough > issue to warrant discussion. I'm getting concerned about the potential > security issues of our contribution model combined with binaries and > upstream patching. One serious security exploit could seriously decimate our > user base. Then again, I'm naturally a bit paranoid about this stuff. > > -- > Cheers, > Mike McQuaid > http://mikemcquaid.com > > -- Best Regards, 崔添翼 (Tianyi Cui, a.k.a. dd_engi) tianyicui@gmail.com +86 13958103659 (It's a prime number!) http://www.google.com/profiles/tianyicui
No need to apologise Adam, you rock.
IMO binary defaults for things like Boost and Qt would be awesome, and we
should do it. These things take so long to compile and MacOS is not
Linux—we can just install binaries.However, of course, we either have to
build and host them ourselves so that the binaries can be trusted, or we
need official binaries from trusted sources (preferably the vendor
themselves).Max
On Nov 8, 2010, at 10:43 PM, Max Howell wrote: <snip> > IMO binary defaults for things like Boost and Qt would be awesome, and we should do it. These things take so long to compile and MacOS is not Linux—we can just install binaries. > > However, of course, we either have to build and host them ourselves so that the binaries can be trusted, or we need official binaries from trusted sources (preferably the vendor themselves). Wonder what the best way to do this is? Something like adding a "--binary" option to the formulas maybe. Probably need a better name than "binary" though. That sounds like it might be related to "binary, the counting system", rather than "binary, the precompiled executables". Maybe "--precompiled" ?
There is no reason to default to source compiles if we have
trusted binaries.So for the hypothetical case where we have binaries that
are trusted and worth using, I suggest a --compile-from-source
option.Max<snip> IMO binary defaults for things like Boost and Qt would be
awesome, and we should do it. These things take so long to compile and
MacOS is not Linux—we can just install binaries. However, of course, we
either have to build and host them ourselves so that the binaries can be
trusted, or we need official binaries from trusted sources (preferably the
vendor themselves).Wonder what the best way to do this is? Something like
adding a "--binary" option to the formulas maybe.Probably need a better
name than "binary" though. That sounds like it might be related to
"binary, thecounting system", rather than "binary, the precompiled
executables".Maybe "--precompiled" ?
I don't see users being happy about typing --compile-from-source, --precompiled or --binary, every time they make a decision on how to install a package. I'd believe shorter parameters are preferred: --bin or --source are simple enough. Also, the user might or might not know if the default for a package is binary or source, so I'd rather have hombrew behave consistently in that aspect: default to source, flag for bin, or vice-versa, whichever is best. Another option would be to have binary formulae with the -bin suffix, as in coreutils-bin, for example (although one could argue that it introduces duplication or noise, and/or more formulae to maintain). Vince On 8 Nov 2010, at 12:27, Max Howell wrote: > > There is no reason to default to source compiles if we have trusted binaries. > > So for the hypothetical case where we have binaries that are trusted and worth using, I suggest a --compile-from-source option. > > Max >> <snip> >>> IMO binary defaults for things like Boost and Qt would be awesome, and we should do it. These things take so long to compile and MacOS is not Linux—we can just install binaries. >>> >>> However, of course, we either have to build and host them ourselves so that the binaries can be trusted, or we need official binaries from trusted sources (preferably the vendor themselves). >> >> Wonder what the best way to do this is? Something like adding a "--binary" option to the formulas maybe. >> >> Probably need a better name t han "binary" though. That sounds like it might be related to "binary, the >> counting system", rather than "binary, the precompiled executables". >> >> Maybe "--precompiled" ? > Vincent Martínez Developer, pebble.it t: 020 3327 1081 http://pebbleit.com
On Nov 8, 2010, at 11:35 PM, Vincent Martínez wrote: > I don't see users being happy about typing --compile-from-source, --precompiled or --binary, every time they make a decision on how to install a package. I'd believe shorter parameters are preferred: --bin or --source are simple enough. "--from-source"? > Also, the user might or might not know if the default for a package is binary or source, so I'd rather have hombrew behave consistently in that aspect: default to source, flag for bin, or vice-versa, whichever is best. Depends upon the "consistency". We could apply consistency of "minimal install time", rather than apply it to the source/binary dimension. Probably not a bad road to take, and seems pretty much what Max is saying. :) > Another option would be to have binary formulae with the -bin suffix, as in coreutils-bin, for example (although one could argue that it introduces duplication or noise, and/or more formulae to maintain). Seems icky.
We're only doing this for two packages, so "every-time" could not
be a more inaccurate statement. And since the user will pass this flag
rarely, verbosity is preferable when you inevitably get blog posts with
copy and paste commands that you can actually—you know—read and make sense
of.Homebrew has always had a policy of not splitting packages out like:
foo-dumb and foo-stupid-crap.I agree regarding your arguments of
consistency. But in my experience, projects of this kind go down the
"CONSISTENCY IS EVERYTHING!!!" route too often and end up being shit. In
my humble opinion we should not be shit.MaxI don't see users being happy
about typing --compile-from-source, --precompiled or --binary, every time
they make a decision on how to install a package. I'd believe shorter
parameters are preferred: --bin or --source are simple enough. Also, the
user might or might not know if the default for a package is binary or
source, so I'd rather have hombrew behave consistently in tha
t aspect: default to source, flag for bin, or vice-versa, whichever is
best. Another option would be to have binary formulae with the -bin
suffix, as in coreutils-bin, for example (although one could argue that it
introduces duplication or noise, and/or more formulae to
maintain). VinceOn 8 Nov 2010, at 12:27, Max Howell wrote:
There is no reason to default to source compiles if we have
trusted binaries.So for the hypothetical case where we have binaries that
are trusted and worth using, I suggest a --compile-from-source
option.Max<snip> IMO binary defaults for things like Boost and Qt would be
awesome, and we should do it. These things take so long to compile and
MacOS is not Linux—we can just install binaries. However, of course, we
either have to build and host them ourselves so that the binaries can be
trusted, or we need official binaries from trusted sources (preferably the
vendor themselves).Wonder what the best way to do this is? Something like
adding a "--binary" option to the formulas maybe.Probably need a better
name t
han "binary" though. That sounds like it might be related to "binary,
thecounting system", rather than "binary, the precompiled
executables".Maybe "--precompiled" ?
Vincent MartínezDeveloper, pebble.itt: 020 3327 1081http://pebbleit.com
On 8 November 2010 04:43, Max Howell <max@methylblue.com> wrote: > I agree regarding your arguments of consistency. But in my experience, > projects of this kind go down the "CONSISTENCY IS EVERYTHING!!!" route too > often and end up being shit. In my humble opinion we should not be shit. +1 to this. The whole point about binaries would be to make certain packages easier/quicker to install. This is OSX and we don't allow users to customise their CFLAGS or whatever so I'm not sure what the advantage would be from compiling from source other than masochism. If everyone complains and there is a good reason to compile from source then we might investigate it otherwise I say we just default to binaries where we can. No idea about hosting locations, anyone got any ideas?. For Qt/Boost we could perhaps use the official binaries (I know they are available for Qt at least) and just install them into a sensible location. Of course, this is a Git based project so people can easily fork and make their own version which uses stupid parameters and source based compilation if they want to and people will use whichever they prefer. This is very much a case where we need to be careful about listening too much to a vocal minority. -- Cheers, Mike McQuaid http://mikemcquaid.com/
On 09/11/2010, at 4:33 PM, Mike McQuaid wrote:
> No idea about hosting locations, anyone got any ideas?.
We might be able to leverage a place like SourceForge or similar.
If that's not workable, then Red Hat employees each have a publicly
accessible account on "people.redhat.com", so I could chuck them there.
(Bandwidth shouldn't be an issue.)
SourceForge (or similar) might be the best bet though, as it allows
multiple people to be given access to upload new things. Using the
people.redhat.com server, I'd have to manually upload things each time.
(it's not a stress, it's just less flexible)
?
Regards and best wishes,
Justin Clift
On 9 Nov 2010, at 03:07, Justin Clift wrote: > On 09/11/2010, at 4:33 PM, Mike McQuaid wrote: >> No idea about hosting locations, anyone got any ideas?. > > We might be able to leverage a place like SourceForge or similar. > > If that's not workable, then Red Hat employees each have a publicly accessible account on "people.redhat.com", so I could chuck them there. > (Bandwidth shouldn't be an issue.) > > SourceForge (or similar) might be the best bet though, as it allows multiple people to be given access to upload new things. Using the people.redhat.com server, I'd have to manually upload things each time. (it's not a stress, it's just less flexible) Sourceforge would also be good as they have localised mirrors. It would be good if someone investigated their terms of use to see if they support this type of thing? -- Cheers, Mike McQuaid http://mikemcquaid.com
I think the skeptics here have really got to think this through. If you install and dont know its a binary - the information will be printed to the stdout. It should be possible to grep the output afterwards, and make a second pass for those packages which will need to be recompiled / reinstalled. At the end of the day the loss for initially installing the binaries is going to be marginal compared to the muchc lengthier compilation times the second time around. Grepping the output to obtain a list of those binary packages you would like to be compiled / reinstalled iswhat most of the critics of this approach seem to be aprehensive about here. Personally I am in favor of binary packages. If you've ever installed something on a debian or ubuntu system you'd understand the reasoning. Its like 1000% faster and less hassle. These days theres fewer reasons to compile each and every time. People who are used to Ports systems often forget that there is an alternative. You can compile once and produce for yourself a custom binary package. Once you've uploaded your signed binary package to a central site (under your username account) then you can share it with others. Install it (as a binary) on multiple machines. Keep it backed up in the cloud. I dont think you can expect any service as comprehensive as what launchpad.net offers for the ubuntu platform. Nevertheless - their basic workflow is correct. Compile Binary package locally -> upload -> download -> install -> download -> install -> download -> install... Update Binary package (recompile) -> upload -> download -> install -> download -> install -> download -> install... Then its simply a case of which package uploaders you trust in the relationship. Be it QT (Trolltech), Homebrew maintainers, or you yourself. On Tue, Nov 9, 2010 at 11:07 AM, Justin Clift <jclift@redhat.com> wrote: > On 09/11/2010, at 4:33 PM, Mike McQuaid wrote: >> No idea about hosting locations, anyone got any ideas?. > > We might be able to leverage a place like SourceForge or similar. > > If that's not workable, then Red Hat employees each have a publicly accessible account on "people.redhat.com", so I could chuck them there. > (Bandwidth shouldn't be an issue.) > > SourceForge (or similar) might be the best bet though, as it allows multiple people to be given access to upload new things. Using the people.redhat.com server, I'd have to manually upload things each time. (it's not a stress, it's just less flexible) > > ? > > Regards and best wishes, > > Justin Clift > > >
> On Tue, Nov 9, 2010 at 11:07 AM, Justin Clift <jclift@redhat.com> wrote: >> We might be able to leverage a place like SourceForge or similar. Looks like github itself has the ability to upload and download files, specifically for this kind of thing: https://github.com/blog/742-new-uploader-downloads-screen "What should you use the downloads section for? The downloads section is a great place to put things that are related to your project, but not necessarily the code. Some examples: • Binary distributions of software"
Some good points all round, don't feel your input is not valued
Vincent, this is a mailing list after all and with that you get a certain
amount of heated debate.I agree binaries are easier for the user, and for
us: building c-software is massively complicated, and most of our issues
are weird compile problems. (Remember, however that on OS X compiling is
easier because almost everyone has an identical (almost) base.)However,
ultimately Homebrew was built for doing development on top of, and we
should remember our roots. `brew edit` is a tenant of homebrew and the
fact that your edits merge with upstream is one of our selling points. So
we shouldn't go to binary-focused IMO.Lets start with Qt and Boost and add
more as we go. As Lee said, we already pick the precompiled Java stuff, so
we're already doing more binaries than we realised.Regarding getting
GitHub to host the binaries. These things will be big. I already feel bad
about stealing all their bandwidth because we're the
biggest project.Trolltech provide a DMG of Qt, I wonder if we can extract
the stuff we need from that? And I'd feel even better if we could torrent
the DMG, they provide that option IIRC.On a side note, do you think we'd
get away with sticking Xcode as a torrent on Pirate Bay? I feel that
forcing everyone to sign up as an Apple developer to use Homebrew sucks.
Maybe we can get Apple to OK it. I doubt it though, so it's tempting just
to do it.MaxOn Tuesday, 9 November 2010 at 12:56, Justin Clift wrote:
On Tue, Nov 9, 2010 at 11:07 AM, Justin Clift wrote:> We
might be able to leverage a place like SourceForge or
similar.@redhat.com>Looks like github itself has the ability to upload and
download files,specifically for this kind of thing:
https://github.com/blog/742-new-uploader-downloads-screen "What should
you use the downloads section for? The downloads section is a great place
to put things that are related to your project, but not necessarily the
code. Some examples: • Binary distributions of software"
On 10/11/2010, at 1:15 AM, Max Howell wrote: <snip> > > On a side note, do you think we'd get away with sticking Xcode as a torrent on Pirate Bay? No, not even slightly. Please don't encourage the breaking of license agreements (really!). > I feel that forcing everyone to sign up as an Apple developer to use Homebrew sucks. Maybe we can get Apple to OK it. Hmmm, Apple might more be thinking along the lines of "We like Homebrew because it gets people to sign up as developers..." If we want to remove the dependency on Xcode, maybe we should have a different dependency? i.e. on "any version of gcc and the autotools installed" Though, I get the feeling that would open its own can of worms.
On 9 Nov 2010, at 08:28, Justin Clift wrote: >> I feel that forcing everyone to sign up as an Apple developer to use Homebrew sucks. Maybe we can get Apple to OK it. > > Hmmm, Apple might more be thinking along the lines of "We like Homebrew because it gets people to sign up as developers..." > > If we want to remove the dependency on Xcode, maybe we should have a different dependency? > > i.e. on "any version of gcc and the autotools installed" > > Though, I get the feeling that would open its own can of worms. Agreed, this seems like it could cause a big mess. It's irritating about Xcode. How do Macports/Fink handle this? I guess another option would be to point people towards BugMeNot which means at least they don't need to sign up. Binaries will help with this, long-term. -- Cheers, Mike McQuaid http://mikemcquaid.com
On 10/11/2010, at 12:47 PM, Mike McQuaid wrote: > On 9 Nov 2010, at 08:28, Justin Clift wrote: >>> I feel that forcing everyone to sign up as an Apple developer to use Homebrew sucks. Maybe we can get Apple to OK it. >> >> Hmmm, Apple might more be thinking along the lines of "We like Homebrew because it gets people to sign up as developers..." >> >> If we want to remove the dependency on Xcode, maybe we should have a different dependency? >> >> i.e. on "any version of gcc and the autotools installed" >> >> Though, I get the feeling that would open its own can of worms. > > Agreed, this seems like it could cause a big mess. > > It's irritating about Xcode. How do Macports/Fink handle this? I guess another option would be to point people towards BugMeNot which means at least they don't need to sign up. Actually, if we know (with accuracy) what the versions of gcc and other bits from Xcode are, we could have a binary package of them somewhere to pull down. For example, lets say it turns out we're only using gcc, make, autoconf, automake, and libtool from Xcode (all GPL or LGPL licensed). If we put get matching versions of them, and put them into a .tar.bz2 somewhere, brew could download and install that if Xcode isn't installed. Might be able to use the versions bundled in Xcode too, as I'm pretty sure they're GPL or LGPL licensed. Still might be safer not to "just in case". :)
On 9 Nov 2010, at 22:24, Justin Clift wrote: > Actually, if we know (with accuracy) what the versions of gcc and other bits from Xcode are, we could have a binary package of them somewhere to pull down. > > For example, lets say it turns out we're only using gcc, make, autoconf, automake, and libtool from Xcode (all GPL or LGPL licensed). If we put get matching versions of them, and put them into a .tar.bz2 somewhere, brew could download and install that if Xcode isn't installed. Good idea, albeit a bit scary. I've tried to build their GCC before and it wasn't totally trivial. > Might be able to use the versions bundled in Xcode too, as I'm pretty sure they're GPL or LGPL licensed. Still might be safer not to "just in case". :) This would be the nicest option if possible. -- Cheers, Mike McQuaid http://mikemcquaid.com
On Wed, Nov 10, 2010 at 2:38 PM, Mike McQuaid <mike@mikemcquaid.com> wrote: > Good idea, albeit a bit scary. I've tried to build their GCC before and it > wasn't totally trivial. > It is not that scary, as Gentoo<http://gentoo-portage.com/sys-devel/gcc-apple>and Macports<http://trac.macports.org/browser/trunk/dports/lang/apple-gcc42/Portfile> has already done the non-trivial part.
GCC is the easiest bit by far. Its all the little libraries. We'd end exactly like MacPorts! On 10 Nov 2010 06:47, "Tianyi Cui" <tianyicui@gmail.com> wrote: > On Wed, Nov 10, 2010 at 2:38 PM, Mike McQuaid <mike@mikemcquaid.com> wrote: > >> Good idea, albeit a bit scary. I've tried to build their GCC before and it >> wasn't totally trivial. >> > > It is not that scary, as > Gentoo<http://gentoo-portage.com/sys-devel/gcc-apple>and > Macports< http://trac.macports.org/browser/trunk/dports/lang/apple-gcc42/Portfile> > has > already done the non-trivial part.
We would like to compile our own binaries for formula that
otherwise take hours to compile, those being Qt and Boost. These binaries
should be built from the Homebrew formulas and hosted somewhere free that
we control.There is no plan to use binaries instead of source in general
(at least for now, but probably ever, despite the benefits). Ultimately
Homebrew is about you being in control. You (the user) can't control
binaries. Homebrew is also about contribution, we have attracted 1500
forks because it is so easy to fix formula issues. Adding additional steps
is not in the game plan.
We aren't going to package our own Xcode because that is just more work
and more potential support tickets that we already struggle to manage.
However it would be nice to offer a direct download to the official Apple
.pkg somehow.
Back to the very beginning, we won't use precompiled packages instead of
source-code unless we trust the source of the binaries.Max
On Tue, Nov 9, 2010 at 10:24 PM, Justin Clift <jclift@redhat.com> wrote: > Actually, if we know (with accuracy) what the versions of gcc and other bits from Xcode are, we could have a binary package of them somewhere to pull down. > > For example, lets say it turns out we're only using gcc, make, autoconf, automake, and libtool from Xcode (all GPL or LGPL licensed). If we put get matching versions of them, and put them into a .tar.bz2 somewhere, brew could download and install that if Xcode isn't installed. > > Might be able to use the versions bundled in Xcode too, as I'm pretty sure they're GPL or LGPL licensed. Still might be safer not to "just in case". :) This could be a great solution---use something like Pacifist: http://www.charlessoft.com/ or Suspicious Package: http://www.mothersruin.com/software/SuspiciousPackage to examine the contents of the Xcode .pkg and find the stuff we want. The it is a matter of using `xar` and `cpio` to extract those bits to re-package. As long as we stick to the GPL stuff, we should be fine. Another alternative would be to grab the Xcode source from: http://www.opensource.apple.com/ And build the Apple-patched tools ourselves. This is how Simon Urbanek builds the Fortran compiler I provide in the gfortran brew: http://r.research.att.com/tools/ -Charlie
On 9 Nov 2010, at 05:33, Mike McQuaid wrote: > On 8 November 2010 04:43, Max Howell <max@methylblue.com> wrote: >> I agree regarding your arguments of consistency. But in my experience, >> projects of this kind go down the "CONSISTENCY IS EVERYTHING!!!" route too >> often and end up being shit. In my humble opinion we should not be shit. > > +1 to this. The whole point about binaries would be to make certain > packages easier/quicker to install. This is OSX and we don't allow > users to customise their CFLAGS or whatever so I'm not sure what the > advantage would be from compiling from source other than masochism. If > everyone complains and there is a good reason to compile from source > then we might investigate it otherwise I say we just default to > binaries where we can. > > No idea about hosting locations, anyone got any ideas?. For Qt/Boost > we could perhaps use the official binaries (I know they are available > for Qt at least) and just install them into a sensible location. > > Of course, this is a Git based project so people can easily fork and > make their own version which uses stupid parameters and source based > compilation if they want to and people will use whichever they prefer. > This is very much a case where we need to be careful about listening > too much to a vocal minority. Personally I do prefer binaries where possible. As you say, OSX users aren't necessarily customising their CFLAGS. My point wasn't that "consistency is everything", but rather that if there're going to be a fair number of packages with both binary and source options, I'd much favour having consistent method, than having to memorise what packages offer what options and how exactly do you pass the flags to each of those packages... akin to a student learning the irregular verbs and their conjugations... But I think you're all getting too fired up on this. Ignore my previous message if that helps. But calling out people's input as a "vocal minority" (was I being vocal about my opinions? sorry if I expressed myself too freely then) and other package managers as "shit" makes me sad I even spoke in the first place. Even if you're right, which you very well may be. Vincent Martínez
On 9 Nov 2010, at 02:04, Vincent Martínez wrote: > Personally I do prefer binaries where possible. As you say, OSX users aren't necessarily customising their CFLAGS. My point wasn't that "consistency is everything", but rather that if there're going to be a fair number of packages with both binary and source options, I'd much favour having consistent method, than having to memorise what packages offer what options and how exactly do you pass the flags to each of those packages... akin to a student learning the irregular verbs and their conjugations... I would agree that consistency here would be a good call (and indeed with the other options we already have) but I think the priority should be getting the defaults right first. > But I think you're all getting too fired up on this. Ignore my previous message if that helps. But calling out people's input as a "vocal minority" (was I being vocal about my opinions? sorry if I expressed myself too freely then) and other package managers as "shit" makes me sad I even spoke in the first place. Even if you're right, which you very well may be. I'm sorry, I really wasn't intending to belittle your opinions at all or refer to you as in the vocal minority. Your explanations were rational and helpful, thanks for them. My point (which I clearly miscommunicated) is that this is the type of decision that encourages a vocal minority to start rudely shouting about why their way is better (unlike a reasoned discussion that we're having now) and threaten to leave Homebrew unless the defaults are changed to what they want. I've seen this in several other open-source projects as both a developer and a user and the minute you get held ransom to shouting idiots rather than your high-level design goals is the minute your projects slides towards mediocrity. I think supporting binaries out of the box would give us a real competitive advantage over Macports and Fink and generally make the tool easier to use. There will still need to be some sort of source option for people like me to be able to actually build on our local machines and upload them. Again, sorry for any offence caused Vincent, it wasn't intended. -- Cheers, Mike McQuaid http://mikemcquaid.com
Just 2c... I sometimes rummage in the formulas but, I'm basically a homebrew _user_. My preference is very strongly for `brew install foo` to just do the right thing and not bother me at all with the details. If the cost of that is a bit of extra complexity when I do do the occasional `brew cat foo` then so be it. (So if there needs to be a binary install I just want that to happen. I'd like to say, "Oh that was quick, I'd heard it took ages to compile" and be none the wiser.) Regards, Carlton
My 2c: The thread has obviously moved around a bit - so this is more a rant about binaries in general :) Something makes me feel uneasy about binaries. No i'm not some sort of Linux open source nazi - however... it's a great way for badness to sneak in. By badness I'm talking security and also missing files, bad build configs and linkage issues for end users when mixing binaries with non-binaries. In fact the last point is probably the main one. # Example time! Say the below thing installs binaries somehow brew install python pip distribute postgres # Ok... pip install psycopg2 # Linking errors go here! I would propose... Java projects - just install the compiled version. We don't want any ant'ness here... dear God no. General libraries that are huge - sure, but only official versions Everything else - source where possible, binary only if not Binary should not be default for the everything else category. But for the first two - it's fine. That's my opinion anyway! </opinionatedrant> Lee. On 9 November 2010 10:13, Carlton Gibson <carlton.gibson@noumenal.co.uk> wrote: > > Just 2c... I sometimes rummage in the formulas but, I'm basically a homebrew _user_. My preference is very strongly for `brew install foo` to just do the right thing and not bother me at all with the details. If the cost of that is a bit of extra complexity when I do do the occasional `brew cat foo` then so be it. > > (So if there needs to be a binary install I just want that to happen. I'd like to say, "Oh that was quick, I'd heard it took ages to compile" and be none the wiser.) > > Regards, > Carlton >
On 9 Nov 2010, at 02:29, Lee Packham wrote: > The thread has obviously moved around a bit - so this is more a rant > about binaries in general :) > > Something makes me feel uneasy about binaries. No i'm not some sort of > Linux open source nazi - however... it's a great way for badness to > sneak in. By badness I'm talking security and also missing files, bad > build configs and linkage issues for end users when mixing binaries > with non-binaries. I think it's less likely for badness to step in if we're generating basically identical output to what we have at the moment and a limited group of people are able to upload. Binaries will certainly be checked more thoroughly than the current source build scripts are. I don't think this is a good reason, both your problems are very speculative. As said before, I don't think badness is more likely to sneak in with binaries. Secondly, security/missing files/linkage issues are clearly avoidable as plenty of people use the binary distributions of Qt. If this experiment doesn't work out (with Boost and Qt) then fair enough but I'm still waiting to hear any good reasons against binaries. Lets not forget that even on the Linux desktop, a vocally source-friendly community, people still prefer binary package managers and distributions over source based ones. I'd like to have a system similar to apt; make binaries the default but have an easily reproducible path if people want to build from source which remains a second-class citizen for packages with binaries available. The main difference should be that we should build from source if we can't find a package, rather than going the apt way of insisting the user takes the long route to build a source package. -- Cheers, Mike McQuaid http://mikemcquaid.com
On 9 Nov 2010, at 10:29, Lee Packham wrote:
> Binary should not be default for the everything else category.
Yes, yes. One of homebrew's selling points is compiling things. I guess my
point was just that where that's not possible/feasible I (qua user) don't
want to know about it.
On 9 Nov 2010, at 02:33, Carlton Gibson wrote: > Yes, yes. One of homebrew's selling points is compiling things. I guess my point was just that where that's not possible/feasible I (qua user) don't want to know about it. It's not an intended selling point and I really think that's a bit of a silly reason. If you end up with an identical binary, how is taking 60m to install Qt rather than 2m a selling point? I used Gentoo for a long time and unless you're providing severe amounts of customisation for most source packages, source distribution is just a complete waste of time for 99% of users. The fact that we're talking on an OSS project list means we're more likely to attract the views of tinkerers here over most of our users who just want to get programs working. -- Cheers, Mike McQuaid http://mikemcquaid.com
On 9 Nov 2010, at 16:19, Mike McQuaid wrote: > On 9 Nov 2010, at 02:33, Carlton Gibson wrote: > >> Yes, yes. One of homebrew's selling points is compiling things. I guess my point was just that where that's not possible/feasible I (qua user) don't want to know about it. > > It's not an intended selling point and I really think that's a bit of a silly reason. If you end up with an identical binary, how is taking 60m to install Qt rather than 2m a selling point? In itself it's not. (Good point, well made :) > The fact that we're talking on an OSS project list means we're more likely to attract the views of tinkerers here over most of our users who just want to get programs working. Perhaps that's it... For me, I like the fact that I can learn a thing or two watching the compile go by... The trouble with, say, apt is that you use it for ages and it still feels like magic... Homebrew is nice in that it helps unwrap a lot of that. The point I'm attached to is trying to keep the `brew` surface layer as simple as possible, that's all. Regards, Carlton
On 9 Nov 2010, at 08:31, Carlton Gibson wrote: > Perhaps that's it... For me, I like the fact that I can learn a thing or two watching the compile go by... The trouble with, say, apt is that you use it for ages and it still feels like magic... Homebrew is nice in that it helps unwrap a lot of that. I heard people saying the same thing about Gentoo. Without meaning to be a patronising dickhead: you aren't learning anything. It's the same logic as people using Linux feeling somehow that they are "almost a programmer" just because they use software that's near impossible to get working. Apologies for my rudeness, I'm just making sure I get decent rebuttals for various reasons before (as I predict) people start complaining about this more vocally and perhaps in the blogosphere. > The point I'm attached to is trying to keep the `brew` surface layer as simple as possible, that's all. Agreed on this, I don't want to overcomplicate things either here. -- Cheers, Mike McQuaid http://mikemcquaid.com
To further elaborate, I'd prefer we didn't have options of this
kind, because it is more to test, so we will only ever prefer binaries
when compiling from source is painful, or takes stupidly long, or is the
only option. But in the first two cases clearly the binary should be the
default, because we are only accepting it because compiling sucks, and in
the latter there is no option.Regarding discoverability, indeed, there is
no easy way to tell about this option. So we write it into the caveats and
plan a utopian future when we make such metadata discoverable without
having to `brew cat foo`.
We're only doing this for two packages, so "every-time" could not
be a more inaccurate statement. And since the user will pass this flag
rarely, verbosity is preferable when you inevitably get blog posts with
copy and paste commands that you can actually—you know—read and make sense
of.Homebrew has always had a policy of not splitting packages out like:
foo-dumb and foo-stupid-crap.I agree regarding your arguments of
consistency. But in my experience, projects of this kind go down the
"CONSISTENCY IS EVERYTHING!!!" route too often and end up being shit. In
my humble opinion we should not be shit.MaxI don't see users being happy
about typing --compile-from-source, --precompiled or --binary, every time
they make a decision on how to install a package. I'd believe shorter
paramet
ers are preferred: --bin or --source are simple enough. Also, the user
might or might not know if the default for a package is binary or source,
so I'd rather have hombrew behave consistently in that aspect: default to
source, flag for bin, or vice-versa, whichever is best. Another option
would be to have binary formulae with the -bin suffix, as in
coreutils-bin, for example (although one could argue that it introduces
duplication or noise, and/or more formulae to maintain). VinceOn 8 Nov
2010, at 12:27, Max Howell wrote:
There is no reason to default to source compiles if we have
trusted binaries.So for the hypothetical case where we have binaries that
are trusted and worth using, I suggest a --compile-from-source
option.Max<snip> IMO binary defaults for things like Boost and Qt would be
awesome, and we should do it. These things take so long to compile and
MacOS is not Linux—we can just install binaries. However, of course, we
either have to build and host them ourselves so that the binaries can be
trusted, or we need official binaries from trusted sources (preferably the
vendor themselves).Wonder what the best way to do this is? Something like
adding a "--binary" option to the formulas maybe.Probably need a better
name t
han "binary" though. That sounds like it might be related to "binary,
thecounting system", rather than "binary, the precompiled
executables".Maybe "--precompiled" ?
Vincent MartínezDeveloper, pebble.itt: 020 3327 1081http://pebbleit.com
On Nov 5, 2010, at 9:10 PM, Mike McQuaid wrote: > https://github.com/mxcl/homebrew/commit/ce3cc386b678de320074c864791ab4a09599faa5#commitcomment-185939 > > I've reverted the unofficial binary added to this package. > > I don't think we should ever accept binaries from anyone except very reputable sources (e.g. the upstream project) and, arguably, shouldn't accept binaries unless the build process is very difficult (which matches this case). Yeah, agreed. Standard good practise. :) > Hope this doesn't step on anyone's toes, I just think it's a big enough issue to warrant discussion. I'm getting concerned about the potential security issues of our contribution model combined with binaries and upstream patching. One serious security exploit could seriously decimate our user base. Then again, I'm naturally a bit paranoid about this stuff. Heh. A SysAdmin at heart I guess. ;)
I apologize for pulling this in. I was "pulling interesting things" and didn't look too hard at this one, especially since I don't use this software package myself. Obviously more eyes on the changes are a good thing. I'll be extra careful about this in the future As far as binary-only packages go, I'm willing to pull out binary-only installs to a new branch (adamv/bin) and move things in here. I personally use the p4 and p4-server brews, but only as a download convenience. I've seen other people using "flex", which is some sort of license server tool, but only comes as a binary. A few things we have as binaries are simply because building them is too hard (Haskel, for instance). But I would be on board with moving things that don't even have source available to a separate branch. Luckily, "brew install" can now work off of URLs and absolute file paths (for formula whose deps all exist in master), so separating things out is becoming less of a burden for users. If no one disagrees, I can set up the "bin" branch for legitimate binary-only installs.
On Nov 6, 2010, at 1:13 AM, Adam Vandenberg wrote: > I apologize for pulling this in. I was "pulling interesting things" > and didn't look too hard at this one, especially since I don't use > this software package myself. Obviously more eyes on the changes are a > good thing. I'll be extra careful about this in the future <snip> > If no one disagrees, I can set up the "bin" branch for legitimate > binary-only installs. Hmmm, it sounds like there's a misunderstanding of some sort. The problem isn't pulling down binaries. It's pulling down (anything) from an "untrusted" source, whether its binary, source-needing-to-be-compiled, or whatever. Or maybe I'm the one misunderstanding? Regards and best wishes, Justin Clift
On 5 Nov 2010, at 14:13, Adam Vandenberg wrote: > I apologize for pulling this in. I was "pulling interesting things" > and didn't look too hard at this one, especially since I don't use > this software package myself. Obviously more eyes on the changes are a > good thing. I'll be extra careful about this in the future Don't worry about it. > As far as binary-only packages go, I'm willing to pull out binary-only > installs to a new branch (adamv/bin) and move things in here. I > personally use the p4 and p4-server brews, but only as a download > convenience. I've seen other people using "flex", which is some sort > of license server tool, but only comes as a binary. > > A few things we have as binaries are simply because building them is > too hard (Haskel, for instance). But I would be on board with moving > things that don't even have source available to a separate branch. I agree with you here. I'm ok with binary-only installs, just not when there is a source version available that's buildable relatively trivially. > Luckily, "brew install" can now work off of URLs and absolute file > paths (for formula whose deps all exist in master), so separating > things out is becoming less of a burden for users. > > If no one disagrees, I can set up the "bin" branch for legitimate > binary-only installs. I'm not sure that's necessary but feel free if you'd like to. I don't have a problem with binaries if that's the only version and if there's no decent existing packaging (e.g. a DMG with .app and Sparkle). -- Cheers, Mike McQuaid http://mikemcquaid.com
Glad you're on the ball Mike. Sent from my iPhone On 5 Nov 2010, at 10:10, Mike McQuaid <mike@mikemcquaid.com> wrote: > https://github.com/mxcl/homebrew/commit/ce3cc386b678de320074c864791ab4a09599faa5#commitcomment-185939 > > I've reverted the unofficial binary added to this package. > > I don't think we should ever accept binaries from anyone except very reputable sources (e.g. the upstream project) and, arguably, shouldn't accept binaries unless the build process is very difficult (which matches this case). > > Hope this doesn't step on anyone's toes, I just think it's a big enough issue to warrant discussion. I'm getting concerned about the potential security issues of our contribution model combined with binaries and upstream patching. One serious security exploit could seriously decimate our user base. Then again, I'm naturally a bit paranoid about this stuff. > > -- > Cheers, > Mike McQuaid > http://mikemcquaid.com >
My two cents on binary distribution is that we should make sure that the user retains the power of choice at a higher level than passing `--binary` or `--build-from-source` every time they have to install or reinstall a formula. There should be something like an environment variable, say HOMEBREW_PREFER_BINARY, which controls the default behavior of `brew install` when it comes to formula that have both binary and source distributions available. A personal case in point is that I switched to having Homebrew build Qt from source after happily using the Trolltech binary distribution for a long time. The reason was that the binary distribution ended up shipping a broken Qt-Dbus module and I happened to need it to get something compiled. I think binary distributions can be great time-savers and make a lot of sense in certain cases but we should always strive to retain as much user choice as possible. Not everyone uses custom CFLAGS or wants to see if everything can be compiled using llvm-gcc or clang, but those of us that do enjoy shooting ourselves in the foot are very grateful that such things can be easily specified in extend/ENV.rb. -Charlie
On 9 Nov 2010, at 09:37, Charlie Sharpsteen wrote: > My two cents on binary distribution is that we should make sure that the user retains the power of choice at a higher level than passing `--binary` or `--build-from-source` every time they have to install or reinstall a formula. There should be something like an environment variable, say HOMEBREW_PREFER_BINARY, which controls the default behavior of `brew install` when it comes to formula that have both binary and source distributions available. No. This is the "death by options" that kills most pieces of software, particularly in the Linux world. Simply allowing the user to choose these things globally makes it too easy for them to configure the software to behave in a stupid fashion. > A personal case in point is that I switched to having Homebrew build Qt from source after happily using the Trolltech binary distribution for a long time. The reason was that the binary distribution ended up shipping a broken Qt-Dbus module and I happened to need it to get something compiled. I think binary distributions can be great time-savers and make a lot of sense in certain cases but we should always strive to retain as much user choice as possible. Bad example. In this case, we'd fix the Trolltech binary distribution if you filed a bug with us. This isn't something that is a good argument for using binaries, just for us to not blindly go "file upstream and leave us alone". > Not everyone uses custom CFLAGS or wants to see if everything can be compiled using llvm-gcc or clang, but those of us that do enjoy shooting ourselves in the foot are very grateful that such things can be easily specified in extend/ENV.rb. Frankly, if you enjoy shooting yourself in the foot then I don't want to expend any effort to help you do so. Messing around with buildsystems is a complete waste of time. You'd actually creating some stuff through programming rather than pissing around with system administration that teaches you nothing and contributes nothing to anyone else. I don't think user choice is a brilliant thing to be focusing on. For each option we add, we make it harder to test and we'll get more bug reports. I'd rather have one route that we support and just keep the code clean enough that people can maintain a fork that e.g. keeps source building as default. -- Cheers, Mike McQuaid http://mikemcquaid.com
On Tue, Nov 9, 2010 at 5:53 PM, Mike McQuaid <mike@mikemcquaid.com> wrote: > On 9 Nov 2010, at 09:37, Charlie Sharpsteen wrote: > > > My two cents on binary distribution is that we should make sure that the user retains the power of choice at a higher level than passing `--binary` or `--build-from-source` every time they have to install or reinstall a formula. There should be something like an environment variable, say HOMEBREW_PREFER_BINARY, which controls the default behavior of `brew install` when it comes to formula that have both binary and source distributions available. > > No. This is the "death by options" that kills most pieces of software, particularly in the Linux world. Simply allowing the user to choose these things globally makes it too easy for them to configure the software to behave in a stupid fashion. From the discussion I have seen so far it looks like the proposal is to create binary distributions for some formula that take a hellish amount of time to compile or constantly suffer from weird edge case bugs. Or formula where the authors of the source constantly yank tarballs without warning *COUGH*PYQT*COUGH*. I think this is an excellent idea. It also looks like the proposed solution is to default to using such binaries, if available, but to retain something like a `--compile-from-source` option for those of us that like to kick it old school. This suggests the implementation will end up looking something like: if ARGV.include? "--compile-from-source" # Homebrew does a source install else # Homebrew does a binary install end My point is that I am one of the people that likes to kick it old school (having a Mac pro that chews through the Qt build at a good clip helps too). I can see myself getting tired of typing `--compile-from-source` every time I install something that I want to compile from source. Therefore, I am suggesting an implementation like: if ARGV.include? "--compile-from-source" or ENV["HOMEBREW_PREFER_SOURCE"] # Homebrew does a source install else # Homebrew does a binary install end This is not a big maintenance nightmare of a suggestion. We already do something much much more complicated with HOMEBREW_USE_LLVM and the issue tracker is not drowning with posts from users exclaiming "HELP! All these formula are broken under LLVM! I hate Homebrew!". I see a slippery slope argument, but no slippery slope. > > A personal case in point is that I switched to having Homebrew build Qt from source after happily using the Trolltech binary distribution for a long time. The reason was that the binary distribution ended up shipping a broken Qt-Dbus module and I happened to need it to get something compiled. I think binary distributions can be great time-savers and make a lot of sense in certain cases but we should always strive to retain as much user choice as possible. > > Bad example. In this case, we'd fix the Trolltech binary distribution if you filed a bug with us. This isn't something that is a good argument for using binaries, just for us to not blindly go "file upstream and leave us alone". The point of this example was that if I can compile things from source, I can fix the problem immediately without waiting for the binary to get fixed. I can also easily install a libfoo that gets compiled "--with-extra-shiny-ponies" without subjecting the Homebrew maintainers to a buch of whining about how the binary doesn't contain ponies that shine the way I want them to. Once again, I am not in any way saying that adding binary distributions is a bad thing. I am just saying that if we have already have a decent source build, we should be careful not to make it any more difficult for people to utilize the source build. > > Not everyone uses custom CFLAGS or wants to see if everything can be compiled using llvm-gcc or clang, but those of us that do enjoy shooting ourselves in the foot are very grateful that such things can be easily specified in extend/ENV.rb. > > Frankly, if you enjoy shooting yourself in the foot then I don't want to expend any effort to help you do so. Messing around with buildsystems is a complete waste of time. You'd actually creating some stuff through programming rather than pissing around with system administration that teaches you nothing and contributes nothing to anyone else. Learning how to get things built is not a waste of time. It takes a sizable group of people who know how to work a buildsystem in order for us to be having a serious discussion about providing pre-built binaries. Homebrew is a perfect playground for honing these skills. We shouldn't take the fun stuff out of the chemistry set just because people can burn themselves if they choose to play with fire. > I don't think user choice is a brilliant thing to be focusing on. For each option we add, we make it harder to test and we'll get more bug reports. I'd rather have one route that we support and just keep the code clean enough that people can maintain a fork that e.g. keeps source building as default. > > Cheers, > Mike McQuaid I don't see source-based brews disappearing any time soon and I hope that Homebrew will always be able to use them. What initially attracted me to this project was how easily `brew create` and `brew edit` finally gave me a git-enabled home for all those "./configure --ten --thousand --options --you --will --never --remember" rattling around in my head. A social network for sharing good ways to invoke configure scripts is one of the cornerstones that makes Homebrew strong and sets it apart from other package managers for OS X. I'm just suggesting that we make it easy for people to stay true to those roots when branch out to pursue new opportunities. -Charlie
On 10/11/2010, at 4:08 PM, Charlie Sharpsteen wrote: > Therefore, I am suggesting an implementation like: > > if ARGV.include? "--compile-from-source" or ENV["HOMEBREW_PREFER_SOURCE"] > # Homebrew does a source install > else > # Homebrew does a binary install > end Personally, I kind of think this is worth trying out and "seeing how it goes". It sounds practical enough. :) > "--with-extra-shiny-ponies" Nifty. I'm am *going* to think of a way to make that an option somewhere. :)
On 9 Nov 2010, at 21:08, Charlie Sharpsteen wrote: > if ARGV.include? "--compile-from-source" or ENV["HOMEBREW_PREFER_SOURCE"] > # Homebrew does a source install > else > # Homebrew does a binary install > end > > This is not a big maintenance nightmare of a suggestion. We already > do something much much more complicated with HOMEBREW_USE_LLVM and the > issue tracker is not drowning with posts from users exclaiming "HELP! > All these formula are broken under LLVM! I hate Homebrew!". > > I see a slippery slope argument, but no slippery slope. And I see a strawman argument where you've assumed the code will be a certain way :) I agree, if it's really that simple, we'll do it (and by we I mean I'll write the code for binary builds and you can support the source ones) ;) >>> A personal case in point is that I switched to having Homebrew build Qt from source after happily using the Trolltech binary distribution for a long time. The reason was that the binary distribution ended up shipping a broken Qt-Dbus module and I happened to need it to get something compiled. I think binary distributions can be great time-savers and make a lot of sense in certain cases but we should always strive to retain as much user choice as possible. >> >> Bad example. In this case, we'd fix the Trolltech binary distribution if you filed a bug with us. This isn't something that is a good argument for using binaries, just for us to not blindly go "file upstream and leave us alone". > > The point of this example was that if I can compile things from > source, I can fix the problem immediately without waiting for the > binary to get fixed. I can also easily install a libfoo that gets > compiled "--with-extra-shiny-ponies" without subjecting the Homebrew > maintainers to a buch of whining about how the binary doesn't contain > ponies that shine the way I want them to. > > Once again, I am not in any way saying that adding binary > distributions is a bad thing. I am just saying that if we have > already have a decent source build, we should be careful not to make > it any more difficult for people to utilize the source build. It'll still be possible to fix problems immediately I'm not planning on closing source all the ways we'll build binaries. It's just a matter of user encouragement, support and publicity. If people learn about building from source by digging through the code or from blogs, no worries, I just won't want us to particularly support it and add to our own workload. > >>> Not everyone uses custom CFLAGS or wants to see if everything can be compiled using llvm-gcc or clang, but those of us that do enjoy shooting ourselves in the foot are very grateful that such things can be easily specified in extend/ENV.rb. >> >> Frankly, if you enjoy shooting yourself in the foot then I don't want to expend any effort to help you do so. Messing around with buildsystems is a complete waste of time. You'd actually creating some stuff through programming rather than pissing around with system administration that teaches you nothing and contributes nothing to anyone else. > > Learning how to get things built is not a waste of time. It takes a > sizable group of people who know how to work a buildsystem in order > for us to be having a serious discussion about providing pre-built > binaries. Homebrew is a perfect playground for honing these skills. > We shouldn't take the fun stuff out of the chemistry set just because > people can burn themselves if they choose to play with fire. You specifically said shooting yourself in the foot. I'd say that's a waste of time. Homebrew is a tool for other people to get stuff done, first and foremost. It's great when open-source projects are fun to contribute to but the main goal should always be being useful rather than allowing people to have fun burning themselves. > >> I don't think user choice is a brilliant thing to be focusing on. For each option we add, we make it harder to test and we'll get more bug reports. I'd rather have one route that we support and just keep the code clean enough that people can maintain a fork that e.g. keeps source building as default. >> >> Cheers, >> Mike McQuaid > > I don't see source-based brews disappearing any time soon and I hope > that Homebrew will always be able to use them. What initially > attracted me to this project was how easily `brew create` and `brew > edit` finally gave me a git-enabled home for all those "./configure > --ten --thousand --options --you --will --never --remember" rattling > around in my head. A social network for sharing good ways to invoke > configure scripts is one of the cornerstones that makes Homebrew > strong and sets it apart from other package managers for OS X. > > I'm just suggesting that we make it easy for people to stay true to > those roots when branch out to pursue new opportunities. Sure. As said, I don't plan to somehow make building binaries invisible. What's most likely is that the first form of binary support will just be a tarball of the built version for 10.6 and 10.5. Later on we might move to using vendor provided binaries or another sophisticated system. -- Cheers, Mike McQuaid http://mikemcquaid.com
On Tue, Nov 9, 2010 at 9:26 PM, Mike McQuaid <mike@mikemcquaid.com> wrote: > > On 9 Nov 2010, at 21:08, Charlie Sharpsteen wrote: > >> if ARGV.include? "--compile-from-source" or ENV["HOMEBREW_PREFER_SOURCE"] >> # Homebrew does a source install >> else >> # Homebrew does a binary install >> end >> >> This is not a big maintenance nightmare of a suggestion. We already >> do something much much more complicated with HOMEBREW_USE_LLVM and the >> issue tracker is not drowning with posts from users exclaiming "HELP! >> All these formula are broken under LLVM! I hate Homebrew!". >> >> I see a slippery slope argument, but no slippery slope. > > And I see a strawman argument where you've assumed the code will be a certain way :) The assumption I made was that a "--compile-from-source" option will be included---that was the impression I got from the discussion in this thread. The thread is 30+ messages long so it is entirely possible that the opinion on that option changed and I didn't notice. But given my assumption that "--compile-from-source" will be offered then: ARGV.include? "--compile-from-source" or some equivalent will be present somewhere in the code. In this case, I offered commentary on implementation details that got dismissed as leading to "death by options". I am objecting to this dismissal if we have already decided on the inclusion of a "--compile-from-source" option for pre-existing formula that we are augmenting with binary distributions. If we haven't, then you have a valid argument and I have been misrepresenting your position. > I agree, if it's really that simple, we'll do it (and by we I mean I'll write the code for binary builds and you can support the source ones) ;) Fine by me. Those binaries don't build themselves ;) >>>> A personal case in point is that I switched to having Homebrew build Qt from source after happily using the Trolltech binary distribution for a long time. The reason was that the binary distribution ended up shipping a broken Qt-Dbus module and I happened to need it to get something compiled. I think binary distributions can be great time-savers and make a lot of sense in certain cases but we should always strive to retain as much user choice as possible. >>> >>> Bad example. In this case, we'd fix the Trolltech binary distribution if you filed a bug with us. This isn't something that is a good argument for using binaries, just for us to not blindly go "file upstream and leave us alone". >> >> The point of this example was that if I can compile things from >> source, I can fix the problem immediately without waiting for the >> binary to get fixed. I can also easily install a libfoo that gets >> compiled "--with-extra-shiny-ponies" without subjecting the Homebrew >> maintainers to a buch of whining about how the binary doesn't contain >> ponies that shine the way I want them to. >> >> Once again, I am not in any way saying that adding binary >> distributions is a bad thing. I am just saying that if we have >> already have a decent source build, we should be careful not to make >> it any more difficult for people to utilize the source build. > It'll still be possible to fix problems immediately I'm not planning on closing source all the ways we'll build binaries. It's just a matter of user encouragement, support and publicity. If people learn about building from source by digging through the code or from blogs, no worries, I just won't want us to particularly support it and add to our own workload. >>>> Not everyone uses custom CFLAGS or wants to see if everything can be compiled using llvm-gcc or clang, but those of us that do enjoy shooting ourselves in the foot are very grateful that such things can be easily specified in extend/ENV.rb. >>> >>> Frankly, if you enjoy shooting yourself in the foot then I don't want to expend any effort to help you do so. Messing around with buildsystems is a complete waste of time. You'd actually creating some stuff through programming rather than pissing around with system administration that teaches you nothing and contributes nothing to anyone else. >> >> Learning how to get things built is not a waste of time. It takes a >> sizable group of people who know how to work a buildsystem in order >> for us to be having a serious discussion about providing pre-built >> binaries. Homebrew is a perfect playground for honing these skills. >> We shouldn't take the fun stuff out of the chemistry set just because >> people can burn themselves if they choose to play with fire. > You specifically said shooting yourself in the foot. I'd say that's a waste of time. Homebrew is a tool for other people to get stuff done, first and foremost. It's great when open-source projects are fun to contribute to but the main goal should always be being useful rather than allowing people to have fun burning themselves. That's just me. I learn best by blowing stuff up and looking at the pieces that come flying out. >>> I don't think user choice is a brilliant thing to be focusing on. For each option we add, we make it harder to test and we'll get more bug reports. I'd rather have one route that we support and just keep the code clean enough that people can maintain a fork that e.g. keeps source building as default. >>> >>> Cheers, >>> Mike McQuaid >> >> I don't see source-based brews disappearing any time soon and I hope >> that Homebrew will always be able to use them. What initially >> attracted me to this project was how easily `brew create` and `brew >> edit` finally gave me a git-enabled home for all those "./configure >> --ten --thousand --options --you --will --never --remember" rattling >> around in my head. A social network for sharing good ways to invoke >> configure scripts is one of the cornerstones that makes Homebrew >> strong and sets it apart from other package managers for OS X. >> >> I'm just suggesting that we make it easy for people to stay true to >> those roots when branch out to pursue new opportunities. > > Sure. As said, I don't plan to somehow make building binaries invisible. What's most likely is that the first form of binary support will just be a tarball of the built version for 10.6 and 10.5. Later on we might move to using vendor provided binaries or another sophisticated system.
On Tue, Nov 9, 2010 at 8:53 PM, Mike McQuaid <mike@mikemcquaid.com> wrote:
> I don't think user choice is a brilliant thing to be focusing on. For
each option we add, we make it harder to test and we'll get more bug
reports. I'd rather have one route that we support and just keep the code
clean enough that people can maintain a fork that e.g. keeps source
building as default.
Amen to that.
-- JD
On Tue, Nov 9, 2010 at 5:37 PM, Charlie Sharpsteen <chuck@sharpsteen.net> wrote: > My two cents on binary distribution is that we should make sure that the > user retains the power of choice at a higher level than passing `--binary` > or `--build-from-source` every time they have to install or reinstall a > formula. There should be something like an environment variable, say > HOMEBREW_PREFER_BINARY, which controls the default behavior of `brew > install` when it comes to formula that have both binary and source > distributions available. No. You would want to set HOMEBREW_OPTS="--binary". That way if there are other option flags etc in the future, just append them to $HOMEBREW_OPTS in ~/.profile and be done with it. > A personal case in point is that I switched to having Homebrew build Qt from > source after happily using the Trolltech binary distribution for a long > time. The reason was that the binary distribution ended up shipping a > broken Qt-Dbus module and I happened to need it to get something compiled. > I think binary distributions can be great time-savers and make a lot of > sense in certain cases but we should always strive to retain as much user > choice as possible. > Not everyone uses custom CFLAGS or wants to see if everything can be > compiled using llvm-gcc or clang, but those of us that do enjoy shooting > ourselves in the foot are very grateful that such things can be easily > specified in extend/ENV.rb. > -Charlie > >