-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added preliminary Dockerfile and tooling #2
base: master
Are you sure you want to change the base?
Added preliminary Dockerfile and tooling #2
Conversation
Reproducible builds are *not ready yet*, but this seems like a step in the right direction.
Caveat: This Dockerfile is only for Debian builds on Buster. |
If this is a preliminary PR, you can mark this as a Draft PR and change it back once it's ready. If someone needs the preliminary code, they can clone from your contrib repo directly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should narrow the scope of your changes a bit more. Right now, your changes are only for Debian, and not for all platforms. Could we change the docker
directory name and the README within to reflect reproducible builds for Debian using Docker?
If we manage to implement reproducibility on more platforms, we can consider merging the efforts.
@@ -2,6 +2,13 @@ | |||
|
|||
A collection of community contributions for [ungoogled-chromium](https://github.com/Eloston/ungoogled-chromium). Inspired by [this blog post by Drew DeVault](https://drewdevault.com/2020/06/06/Add-a-contrib-directory.html) | |||
|
|||
## Layout | |||
|
|||
All docker-related things are in [`/docker`](/docker) and are mostly intended to move ungoogled-chromium towards a more reproducible build system. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's necessary to have a Layout section, because anyone can contribute anything to contrib at any point. Too much structure makes things difficult, and we should minimize difficulty.
It should be sufficient to simply have a README.md
inside your docker directory, as users should find that on their own without any indication.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should narrow the scope of your changes a bit more. Right now, your changes are only for Debian, and not for all platforms. Could we change the
docker
directory name and the README within to reflect reproducible builds for Debian using Docker?If we manage to implement reproducibility on more platforms, we can consider merging the efforts.
Fair point! Does a /scripts/builds
thing work or were you thinking of something else?
I'll put a thing in the README about all the scripts being in /scripts
if you think that's best -- if not, I'll remove the layout section entirely.
Reproducible builds is one of the main goals of having a Dockerfile build process, but it isn't the only main goal -- it's also great if users want to build it themselves (all they need to do is build the Dockefile). I'm thinking about perhaps adding Dockerfiles for other architectures/OSes before I get reproducible builds working.
Lmk what you think -- I'm not particularly attached to any of the above ideas.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe a directory like reproducible-debian
? If we want to add more code regarding reproducibility in the future, then we could move your code into reproducible-debian/docker
.
Reproducible builds is one of the main goals of having a Dockerfile build process, but it isn't the only main goal -- it's also great if users want to build it themselves (all they need to do is build the Dockefile)
Docker is pretty useful, but I don't agree with your premise (i.e. easier for users to build it themselves) for a few nitpicky reasons:
- I think Docker adds another unnecessary layer. The overhead of Docker is higher than users installing the build dependencies directly on their system. Not only does it take more space, but Docker is pretty invasive, configuring kernel-level stuff like nftables (for NAT). While you could probably configure Docker not to do this, it's not ideal for a user who likes to have a comprehensive understanding and control of their system (an analogy would be someone's personal garden).
- Docker only works for Linux systems. It won't help us with reproducibility for macOS and Windows.
- I'd argue that the build process for all platforms can be made nearly as simple as a Dockerfile, if need to be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've used Docker on both Debian and macOS to build UC so here are my opinions:
-
Docker on macOS is possible, but very inefficient since it needs a VM to run. Meanwhile if you do not have UI access to the mac machine you cannot use VirtualBox due to a copyright/license problem I think, and the other VM is old and not well maintained.
-
If the user uses a remote machine for building, than Docker can potentially be a necessary tool. There exists a lot of cloud solutions based on Docker so I believe it is not much riskier than, say running a LAMP stack. The reason I used Docker is there are often a lot of restrictions on remote machines, for example:
- The machines themselves are often virtualized in KVM or Xen so you cannot use type 2 hypervisors inside it, including KVM and VirtualBox
- There are often limited offering of OSes by cloud provider. For example, Gaudi.net (the one I am using for Android build) does not have Fedora so I have to use Docker on Debian
In these cases, Docker is basically the only way to get a working environment.
I think a reasonable point is that, Docker and Dockerfile can be useful for those who need it, and it can potentially be more friendly to users who want to make small changes to the project. IMO the problem it solves better is a quick to establish development/build environment, reproducibility is a nice addon.
Reproducible builds are not ready yet, but this seems like a step in the right direction.
However, this stuff should make it much easier to get a working build on your machine regardless, so it's useful anyways. No more environment headaches (if any existed previously). Should be as simple as a one-click build.