Skip to content
This repository has been archived by the owner on Mar 12, 2019. It is now read-only.

Merge Linuxbrew/brew into Homebrew/brew #612

Closed
8 of 9 tasks
sjackman opened this issue Feb 20, 2018 · 44 comments
Closed
8 of 9 tasks

Merge Linuxbrew/brew into Homebrew/brew #612

sjackman opened this issue Feb 20, 2018 · 44 comments
Assignees

Comments

@sjackman
Copy link
Member

sjackman commented Feb 20, 2018

We aim to merge Linuxbrew/brew into Homebrew/brew by the end of 2018. Linux users will use Homebrew/brew. Linuxbrew/brew will remain as a fork to be used for development.

This list is not comprehensive and will be expanded as items arise.

Once these tasks are complete, we'll migrate from Linuxbrew/brew to Homebrew/brew in this order:

  1. Move Linuxbrew CI to using Homebrew/brew
  2. Move Linuxbrew master branch users to using Homebrew/brew's master branch
  3. Move Linuxbrew stable/tag users to using Homebrew/brew's master branch
@MikeMcQuaid
Copy link
Contributor

Suggestion for ordering this migration:

  1. Move Linuxbrew CI to using Homebrew/brew
  2. Move Linuxbrew master branch users to using Homebrew/brew's master branch
  3. Move Linuxbrew stable/tag users to using Homebrew/brew's master branch

Additional tasks:

  • Document what Linux platforms Homebrew/brew officially supports (likely a single distro and a lower level than Linuxbrew/brew). Instead or as well: consider what the bug reporting/fixing flow is going to look like
  • Document Linux behaviour in documentation e.g. manpage
  • Figure out a solution for MacOS.version
  • Ensure Homebrew/brew on Linux can brew readall Homebrew/homebrew-core and/or Linuxbrew/homebrew-core (probably both)

@sjackman
Copy link
Member Author

sjackman commented Feb 20, 2018

These all look good. I've added them to the tracking issue above.

Document what Linux platforms Homebrew/brew officially supports (likely a single distro and a lower level than Linuxbrew/brew)

Linuxbrew builds its bottles on the most recent Ubuntu LTS platform, which is currently Ubuntu 16.04 LTS (Xenial Xerus) and in April will become Ubuntu 18.04 LTS (Bionic Beaver). Other distributions that I'd like to support are Debian, Fedora, and CentOS. The popularity of distribution and version being run on Google Analytics in the last 30 days, in order of popularity, are Ubuntu 16.04, Ubuntu 17.10, Fedora Core 27, Debian 8, Ubuntu 14.04, Ubuntu 12.04, CentOS 7, and Debian 9.

Rank Distribution Total Events Unique Events
1. Ubuntu 16.04.3 LTS 10,034(19.35%) 9,702(19.77%)
2. Ubuntu 16.04.3 LTS, custom-prefix 7,264(14.01%) 6,959(14.18%)
3. Ubuntu 17.10 5,833(11.25%) 5,595(11.40%)
4. 4.13.9-300.fc27.x86_64 1,397(2.69%) 1,305(2.66%)
5. Debian GNU/Linux 8.10 (jessie), custom-prefix 1,030(1.99%) 887(1.81%)
6. Ubuntu 14.04.5 LTS 843(1.63%) 812(1.65%)
7. 4.4.0-111-generic, CI 823(1.59%) 823(1.68%)
8. Ubuntu 16.04.2 LTS 767(1.48%) 738(1.50%)
9. "CentOS Linux release 7.4.1708 (Core) " 745(1.44%) 728(1.48%)
10. Debian GNU/Linux 9.3 (stretch) 690(1.33%) 672(1.37%)

@sjackman
Copy link
Member Author

  • Figure out a solution for MacOS.version
  • Ensure Homebrew/brew on Linux can brew readall Homebrew/homebrew-core and/or Linuxbrew/homebrew-core (probably both)

Current Homebrew/brew on Linux cannot tap Homebrew/core due to…

undefined method `full_version' for OS::Mac:Module
undefined method `version' for OS::Mac::Xcode:Module
undefined method `version' for OS::Mac:Module

@MikeMcQuaid How do you feel about defining these three methods as Version::NULL on Linux?

@MikeMcQuaid
Copy link
Contributor

@MikeMcQuaid How do you feel about defining these three methods as Version::NULL on Linux?

@sjackman That seems reasonable 👍 .

Linuxbrew builds its bottles on the most recent Ubuntu LTS platform, which is currently Ubuntu 16.04 LTS (Xenial Xerus) and in April will become Ubuntu 18.04 LTS (Bionic Beaver).

Cool. I think we should stick with the latest Ubuntu LTS and ensure that our Linux brew tests job is running there, if possible.

@sjackman
Copy link
Member Author

sjackman commented Feb 20, 2018

Cool. I think we should stick with the latest Ubuntu LTS and ensure that our Linux brew tests job is running there, if possible.

Use Docker on TravisCI? I haven't used it yet, but seems supported (https://docs.travis-ci.com/user/docker/). Docker support on CircleCI 2.0 is first class.

@sjackman
Copy link
Member Author

sjackman commented Feb 20, 2018

@MikeMcQuaid How do you feel about defining these three methods as Version::NULL on Linux?

@sjackman That seems reasonable 👍 .

I've submitted PR Homebrew/brew#3820. There's also MacOS.prefer_64_bit?. That's the last one. Shall I rename this method to OS.prefer_64_bit? and submit PRs to Homebrew/brew and Homebrew/homebrew-core? I'll keep the old name as a deprecated alias.

@MikeMcQuaid
Copy link
Contributor

I've submitted PR Homebrew/brew#3820. There's also MacOS.prefer_64_bit?. That's the last one. Shall I rename this method to OS.prefer_64_bit? and submit PRs to Homebrew/brew and Homebrew/homebrew-core? I'll keep the old name as a deprecated alias.

prefer_64_bit? has always felt a bit weird as a name to me. What about just OS.64_bit? or OS.is_64_bit? CC @ilovezfs in case you have other good naming thoughts.

Use Docker on TravisCI? I haven't used it yet, but seems supported (https://docs.travis-ci.com/user/docker/). Docker support on CircleCI 2.0 is first class.

What's the distro that the base Travis CI image is running?

@ilovezfs
Copy link
Contributor

I guess OS.64_bit? seems fine. Apple is dropping 32-bit support altogether so we may also want a OS.64_bit_only? if that helps inform your naming thoughts at all.

@sjackman
Copy link
Member Author

I liked OS.64_bit?

What's the distro that the base Travis CI image is running?

Ubuntu 12.04 LTS (Trusty Tahr), which is six years old now.

@ilovezfs
Copy link
Contributor

I'm confused. https://docs.travis-ci.com/user/reference/overview/

Sudo-enabled #

A sudo enabled, full virtual machine per build, that runs Linux, either Ubuntu Precise 12.04 or Ubuntu Trusty 14.04.
Container-based #

A fast boot time environment in which sudo commands are not available. Running Linux Ubuntu Trusty 14.04

@sjackman
Copy link
Member Author

sjackman commented Feb 21, 2018

You're right. I had forgotten that TravisCI offers both Precise and Trusty. Ubuntu 14.04 LTS (Trusty Tahr) is four years old. TravisCI does not offer the current Ubuntu 16.04 LTS (Xenial Xerus). Ubuntu 18.04 LTS (Bionic Beaver) will be released in April.

@sjackman
Copy link
Member Author

Here's the list of essential (required) Debian packages. It's pretty safe to assume that these packages will be available on most Linux systems.
See https://www.reddit.com/r/debian/comments/6lnakq/what_are_the_essential_packages/

base-files              libattr1                libuuid1
base-passwd             libblkid1               login
bash                    libc-bin                lsb-base
bsdutils                libc6                   mawk
coreutils               libcomerr2              mount
dash                    libfdisk1               multiarch-support
debconf                 libgcc1                 ncurses-base
debianutils             liblzma5                ncurses-bin
diffutils               libmount1               passwd
dpkg                    libpam-modules          perl-base
e2fslibs                libpam-modules-bin      sed
e2fsprogs               libpam-runtime          sensible-utils
findutils               libpam0g                sysvinit-utils
gcc-6-base              libpcre3                tar
grep                    libselinux1             tzdata
gzip                    libsepol1               util-linux
hostname                libsmartcols1           zlib1g
init-system-helpers     libss2
libacl1                 libtinfo5

@sjackman sjackman mentioned this issue Jul 5, 2018
6 tasks
@jamescostian
Copy link
Contributor

Is there anything that an outsider could do to help this merger? The todo list at the top seems like it may be out of date (e.g. "Figure out a solution for MacOS.version" seems to be resolved by a comment here and "Document what Linux platforms Homebrew/brew officially supports" seems to be resolved by another comment) so if anyone has a more up-to-date list of issues, I'd be happy to try and tackle some.

@iMichka
Copy link
Member

iMichka commented Aug 6, 2018

I think we need to rework that list a little bit :)

@sjackman
Copy link
Member Author

sjackman commented Aug 8, 2018

@jamescostian At this point, Homebrew/brew should be usable with Linuxbrew/core, so end-user testing would be helpful. Install Linuxbrew, and then change ~/.linuxbrew/Homebrew to use the Homebrew/brew remote rather than the default Linuxbrew/brew. If you run into any problems or have questions / need help, open a new issue at Linuxbrew/brew.

@MikeMcQuaid
Copy link
Contributor

@sjackman That's pretty exciting. What are the main things that remain unmerged?

@sjackman
Copy link
Member Author

sjackman commented Aug 14, 2018

It is pretty exciting! For example brew install brewsci/bio/miniasm works 💯 using Homebrew/brew, and pours the bottle!

Here's most of the remaining differences.

  • HOMEBREW_BOTTLE_DEFAULT_DOMAIN is https://linuxbrew.bintray.com on Linux
  • Default core tap is https://github.com/Linuxbrew/homebrew-core on Linux
  • Find the host's GNU compiler e.g. /usr/bin/gcc, default compiler is gcc
  • Symlink the dynamic linker ld.so
  • Various fixes to stdenv for Linux (though superenv is the default)
  • Linuxbrew's bottles are built for glibc 2.23, so install the brewed glibc and gcc if the host's glibc is older than 2.23
  • depends_on :java installs the formula openjdk on Linux
  • depends_on :x11 installs the formula linuxbrew/xorg/xorg on Linux
  • Ignore keg_only when :provided_by_macos, :provided_by_osx, :shadowed_by_macos on Linux
  • brew linkage checks for undesirable linking to host libraries on Linux
  • Default installation prefix is /home/linuxbrew/.linuxbrew on Linux
  • Treat cellar :any_skip_relocation as cellar :any on Linux, since relocation is always needed
  • Print a dot each minute during brew uses. This may no longer be necessary.
  • Environment variable HOMEBREW_ARCH specifies the value of cc -march=…, useful when installing formulae on one machine to NFS, but then running those executables on a machine with an older CPU, e.g. HOMEBREW_ARCH=core2. Particularly useful for HPC systems with a newer head job submission node, but older compute nodes.
  • Add a Dockerfile to build a Docker image with a Docker Hub automated build

@MikeMcQuaid
Copy link
Contributor

HOMEBREW_BOTTLE_DEFAULT_DOMAIN is https://linuxbrew.bintray.com on Linux
Default core tap is https://github.com/Linuxbrew/homebrew-core on Linux
Find the host's GNU compiler e.g. /usr/bin/gcc-5 or /usr/bin/gcc44
Various fixes to stdenv for Linux (though superenv is the default)
Linuxbrew's bottles are built for glibc 2.23, so install the brewed glibc and gcc if the host's glibc is older than 2.23
depends_on :java installs the formula jdk on Linux
depends_on :x11 installs the formula linuxbrew/xorg/xorg on Linux
Ignore keg_only when :provided_by_macos, :provided_by_osx, :shadowed_by_macos on Linux
brew linkage checks for undesirable linking to host libraries on Linux
Default installation prefix is /home/linuxbrew/.linuxbrew on Linux
Treat cellar :any_skip_relocation as cellar :any on Linux, since relocation is always needed
Environment variable HOMEBREW_ARCH specifies the value of cc -march=…, useful when installing formulae on one machine to NFS, but then running those executables on a machine with an older CPU, e.g. HOMEBREW_ARCH=core2. Particularly useful for HPC systems with a newer head job submission node, but older compute nodes.

These all seem reasonable and mergeable 👍

Print a dot each minute during brew uses. This may no longer be necessary.

I think we've handled this with brew test-bot now for Travis CI. It's also a bunch faster with the newer Ruby we're on now.

@maxim-belkin
Copy link
Contributor

Print a dot each minute during brew uses. This may no longer be necessary.

I think we've handled this with brew test-bot now for Travis CI. It's also a bunch faster with the newer Ruby we're on now.

For Linuxbrew, when something depends on linuxbrew/xorg/xorg (or some other package from linuxbrew/xorg) we end up with a longer-than-on-macOS list of dependencies. So, it's not directly related to the speed at which Ruby does things.

@iMichka
Copy link
Member

iMichka commented Sep 6, 2018

depends_on :x11 installs the formula linuxbrew/xorg/xorg on Linux

I do not do that anymore in core. This got broken at one point, so I am using depends on "linuxbrew/xorg/xorg". I also noticed that it is often overkill to depend on the full xorg formula and went for a more fine-grained selection of dependencies.

@sjackman
Copy link
Member Author

sjackman commented Sep 6, 2018

Thanks for the information, Michka! That should reduce a big part of the diff in superenv.

@MikeMcQuaid
Copy link
Contributor

Various fixes to stdenv for Linux (though superenv is the default)

Sounds like from Homebrew/brew#4831 (comment) this can be removed for now.

depends_on :java installs the formula jdk on Linux
depends_on :x11 installs the formula linuxbrew/xorg/xorg on Linux

It would be interesting to explore whether openjdk and even xorg can be usefully built and used on macOS. It would be neat to make two big, open source cask dependencies not require manual installation.

@sjackman
Copy link
Member Author

sjackman commented Sep 6, 2018

Various fixes to stdenv for Linux (though superenv is the default)

Sounds like from Homebrew/brew#4831 (comment) this can be removed for now.

Some fixes will be necessary, but I've struck out this item for now. It's not a priority, since Superenv is the default, and works great.

depends_on :java installs the formula jdk on Linux
depends_on :x11 installs the formula linuxbrew/xorg/xorg on Linux

It would be interesting to explore whether openjdk and even xorg can be usefully built and used on macOS. It would be neat to make two big, open source cask dependencies not require manual installation.

That would be pretty cool. I'm not myself the person to take up the torch of creating those formulae. It'd be awesome if someone did pick it up.

@MikeMcQuaid
Copy link
Contributor

Some fixes will be necessary, but I've struck out this item for now. It's not a priority, since Superenv is the default, and works great.

👍

That would be pretty cool. I'm not myself the person to take up the torch of creating those formulae. It'd be awesome if someone did pick it up.

Agreed and same here 😁 (for now at least).

@alebcay
Copy link
Contributor

alebcay commented Sep 13, 2018

That would be pretty cool. I'm not myself the person to take up the torch of creating those formulae. It'd be awesome if someone did pick it up.

I'm looking into making an openjdk formula, but it seems that the build process requires an existing Java compiler on the PATH in order to work (a bootstrap JDK).

@sjackman
Copy link
Member Author

Homebrew has allowed using precompiled binaries in this case to bootstrap compiling the packaged compiler from source.

@alebcay
Copy link
Contributor

alebcay commented Sep 15, 2018

What is the status of https://github.com/Linuxbrew/homebrew-core/pull/8977? I have an OpenJDK formula in the works (one that completely builds from the source tarballs pulled from the OpenJDK mercurial), but I see there's already a PR in progress.

@iMichka
Copy link
Member

iMichka commented Sep 15, 2018

I still need to review it. If you have some comments for that new formula, they are welcome of course :)

@alebcay
Copy link
Contributor

alebcay commented Sep 15, 2018

No, nothing in particular. I was just curious on which, if either, approach (from ojdkbuild or building ourselves) was preferable. It would save me some time so I could start working towards making the xorg formulas build from scratch. 😄

@maxim-belkin
Copy link
Contributor

I could start working towards making the xorg formulas build from scratch

They build from scratch just fine. Some need to be update to account for a recent switch to real superenv, but otherwise...

@sjackman
Copy link
Member Author

PR https://github.com/Linuxbrew/homebrew-core/pull/8977 installs prebuilt binaries of OpenJDK for Linux, which is okay in Linuxbrew/core, but not okay for Homebrew/core. The maintainers of Homebrew/core have expressed that they would like an openjdk formula that builds it from source. Would you be interested in submitting your formula upstream to Homebrew/core? Do you use or have access to a macOS machine?

@sjackman
Copy link
Member Author

If so, the formula submitted upstream to Homebrew/core would need to support only macOS. Linuxbrew/core is a fork of Homebrew/core, and the formula here in Linuxbrew/core would support both macOS and Linux.

@alebcay
Copy link
Contributor

alebcay commented Sep 18, 2018

Would you be interested in submitting your formula upstream to Homebrew/core? Do you use or have access to a macOS machine?

Yes, in that case, I'll take it over to the Homebrew/core side then.

@sjackman
Copy link
Member Author

Excellent! That's great, Caleb.

@MikeMcQuaid
Copy link
Contributor

Is there much more to do here for this to be merged?

@sjackman
Copy link
Member Author

The substantial portions of the merger are complete. Homebrew/brew is now quite usable on Linux! Linuxbrew/test-bot ought to be merged into Homebrew/test-bot. Linuxbrew developers and beta testers need to give Homebrew/brew on Linux a spin. Then it'll be rolled out to CI on Brewsci/bio and Linuxbrew/core. Then it'll be rolled out to users with homebrew.devcmdrun=1, and finally to all users.

@MikeMcQuaid
Copy link
Contributor

The substantial portions of the merger are complete.

What portions are left?

Linuxbrew developers and beta testers need to give Homebrew/brew on Linux a spin. Then it'll be rolled out to CI on Brewsci/bio and Linuxbrew/core. Then it'll be rolled out to users with homebrew.devcmdrun=1, and finally to all user

Cool, sounds good. Would be good to have this on CI within a few weeks if we want to hit the goal of rolling out to all users by the end of the year.

@sjackman
Copy link
Member Author

sjackman commented Oct 31, 2018

What portions are left?

  • Patches related to the :java and :x11 requirements, which may no longer be needed, since Requirements were largely phased out.
  • Fixes for Stdenv, which have not yet been ported to Homebrew/brew. They're not a priority for me, since we've been using Superenv for a couple of years now.
  • A fix to prevent using brewed glibc 2.23 on systems with Linux kernel < 2.6.32, because glibc 2.23 requires Linux kernel ≥ 2.6.32. These systems cannot use bottles and must build everything from source using their host's glibc. These systems are not supported.
  • A patch to prefer gcc-5 over larger versions as the default compiler, because bottles are built using GCC 5 on Ubuntu 16.
  • A patch to automatically symlink /usr/bin/gcc to $HOMEBREW_PREFIX/bin/gcc-X (where X is its version), which should no longer be needed.
  • A workaround to install bottles that were built during a period ~1.5 years ago with a bug that caused the placeholder token @@HOMEBREW_REPOSITORY@@ to be used when it should be @@HOMEBREW_PREFIX@@, due to building bottles on CI before migrating the directory structure to $HOMEBREW_REPOSITORY=$HOMEBREW_PREFIX/Homebrew. This fix may still be needed. I'm unsure how many bottles remain that were built during this time period
  • A patch block implies a build dependency on gpatch.
  • A random fix for utils/lock.sh for systems that do not support file descriptors above 200.

Other miscellaneous patches, which with any luck are no longer needed.

Fixes for Linuxbrew/core CI

  • Fixes for brew bottle --keep-old to deal with the case when the value detected for cellar on macOS is different than the value detected on Linux.
  • Add a --tap option to brew pull to handle the case that brew pull --tap=homebrew/core https://github.com/Linuxbrew/homebrew-core/pull/123 is for the tap homebrew/core, not linuxbrew/core as implied by the pull URL.
  • Support for building bottles from a pull request whose head is a merge commit, when Homebrew/core is merged into Linuxbrew/core and submitted to a PR.

My plan is to merge chunks on an as-needed basis from hereon.

@sjackman sjackman mentioned this issue Nov 2, 2018
6 tasks
@eiennohito
Copy link

Release without support for HOMEBREW_ARCH have broken my installation :(

@sjackman
Copy link
Member Author

Hi, Arseny. That HOMEBREW_ARCH feature has been removed from Linuxbrew as part of the merging of Linuxbrew/brew into Homebrew/brew, because Homebrew did not have this feature, and due to bit rot, it hadn't actually been working in a while (specifically, it was implemented for --env=std, but never for --env=super, and Linuxbrew switched to --env=super over a year ago`). I recommend installing packages on a machine that has the oldest CPU architecture that you are using.

@sjackman
Copy link
Member Author

sjackman commented Dec 18, 2018

@MikeMcQuaid Here's the list of supported distributions of Linux. Your thoughts? Shall I open a PR to create docs/Linux.md?

Edit: Moved this comment to Homebrew/brew#4758 (comment)

@sjackman
Copy link
Member Author

sjackman commented Jan 7, 2019

The last remaining item is Merge Linuxbrew/homebrew-test-bot into Homebrew/homebrew-test-bot.
This issue has moved to Homebrew/brew#4758

@sjackman sjackman closed this as completed Jan 7, 2019
@Linuxbrew Linuxbrew locked as resolved and limited conversation to collaborators Jan 7, 2019
@sjackman
Copy link
Member Author

sjackman commented Jan 7, 2019

Homebrew/brew 1.9.0 will include beta support for Linux!
🥂 🎆

@sjackman
Copy link
Member Author

Homebrew/brew 1.9.0 includes beta support for Linux and Windows 10!
https://brew.sh/2019/01/09/homebrew-1.9.0/

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants