Repo refactor (keep it simple and separate concerns)

[fsquillace]

Hi guys,

I would like to raise some concerns about the direction that this repo is getting so far.
In particular, there are three issues that I could see here.

Keep it simple

Lately, I have seen few changes about this repo that attempt to introduce docker as a way to build the static proot executable.

I believe that the goal of this repo is quite different indeed. This repo should only contains a makefile and it is up to the user to decide which backend for the provisioning of machines needs to be used.

If you really want to have docker, I suggest to use a different repo for such purpose a leave this repo as simple as possible in order to be easily consumed by anyone.

Also, CARE is a completely different project and, IMHO it should be placed in a different repo in order to facilitate the maintenance of it.

Repo size

Another concern is about the fact that this repo is too big now (480MB) because of all the binary files in it:

vagrant@slackware64-14:~$ git clone https://github.com/fsquillace/proot-static-build.git proot-static-build
Cloning into 'proot-static-build'...
remote: Counting objects: 280, done.
remote: Total 280 (delta 0), reused 0 (delta 0), pack-reused 280
Receiving objects: 100% (280/280), 480.75 MiB | 1.93 MiB/s, done.
Resolving deltas: 100% (129/129), done.
Checking connectivity... done.
Checking out files: 100% (23/23), done.

I think that all the binary files should go away from this repo.

Dynamically points to different PRoot code

The current makefile contains an hardcoded version of the PRoot code. I think that the user needs to decide which proot code need to be statically linked.

Solution

I have built my version of such repo which contains only a makefile and addressed all the issue previously mentioned.

If you believe on such approach, I would like to contribute on proot
project in order to build the new proot-static-build from scratch in proot-me organization.
My second goal would be to build a new repo that statically build proot via
Vagrant. Vagrant suits much better for this purpose compared to Docker as it
allows to have the provisioning of machines on different architectures (i686 and ARM).

WDYT guys?

[jopasserat]

Hey @fsquillace, thanks for the feedback!
Here're my (late but hopefully thorough) opinions:

Moving CARE to a different project

Yes it would be a good idea but I have absolutely no idea how that would impact the development.
What will have to be imported and how? Typically the header files? It's not like in Java where you have all the artefacts repos which you can draw jars from.

Do you have any design idea suggesting what it would look like?

Repo size

Definitely agree!
When I have time:

• I'll remove the binaries and keep only the library dependencies.
• I'll migrate the repo to git LFS

Dynamically points to different PRoot code

Can you expand a bit on that one?
And potentially submit a PR for what you think would be a good way of doing it?

Solution

Happy to merge parts of your Makefile in this one if it improves on the previous point.
PR is the way ❤️

Vagrant vs Docker

We need Docker...

I disagree that Vagrant suits builds better than Docker, since Docker is fairly well integrated with CIs.

I've recently noticed (shame on me) the cross-build-env folder in the PRoot source tree. I believe it contains scripts to cross-build PRoot for different architectures.

I don't have any expertise with that myself but would be great to investigate this solution or reuse parts of it.

Also, maybe these scripts should be moved here?

... but we also need Vagrant

But Vagrant would help new contributors getting started with PRoot development so please PR a nice Vagrantfile!!

I think both the Vagrantfile(s) and Dockerfile(s) should stay in the repo as they:

• are an inherent part of the development cycle
• don't harm the size
• can be hidden in a subfolder if you don't want them as top folder elements

Communication

We've opened a gitter channel for development related discussions: https://gitter.im/proot-me/devs

You should be able to join but if not ping me :)

Gitter is probably better than issues for long discussions (and it's now Free and Open Source 😄)

[fsquillace]

Dynamically points to different PRoot code

I was thinking something like the solution I proposed.
Namely, as such repo contains the way proot needs to be built, such repo should have the ability to choose which source take into account. For instance, via proot-url variable you can define what is the source to consider:

make proot proot-url=https://github.com/myuser/PRoot.git proot-branch=myproot

Vagrant vs Docker

I agree with you about the fact that even docker can be a good choice. In fact, there is no so much support for vagrant in CIs (which is an issue I have struggled with). I believe that both Docker and Vagrant are useful indeed. For my project I do need to use Vagrant only as it allows me to build proot for different architectures. My proposal is to separate building part with the provider used into two different repositories, as they are, IMHO, two separate concerns. For instance I use proot-vagrant which takes the proot-static build and provisions a machine using any provider via Vagrant. If someone else wants to use a different approach (neither Docker nor Vagrant) they can still use the basic proot-statci build code.

Moving CARE to a different project

As I have not seen any benefits of having CARE into the proot makefile I have removed any target (and its related dependecies) to obtain something like this.

Communication

Yes, I will communicate with gitter for further issues in the future. For this specific issue we may want to keep in the github issues for a bit more visibility.

[oxr463]

On Moving Care...

Also, CARE is a completely different project and, IMHO it should be placed in a different repo in order to facilitate the maintenance of it.

Yes it would be a good idea but I have absolutely no idea how that would impact the development.

Moving CARE seems unnecessary since both applications utilize the same source tree. There are many projects that contain multiple tools in one repository since they share code so I don't think we should worry about this unless they somehow diverge.

Static Releases

Static binaries can and should be released along with source code distributions via GitHub releases from the main repository. That requires a bit more work with our current continuous integration pipeline, but eventually this repository should be deleted, (or at least archived and/or all binary files removed).

Docker vs Vagrant - Why not both?

Feel free to submit a Vagrant file if you'd like, but Docker is vital for continuous integration;
being able to recreate the exact same environment locally as if it were running on travis (or circle-ci, gitlab, etc.), is invaluable and can save development time when troubleshooting.