Skip to content
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

Simplify the installation procedure. #163

Closed
ydahhrk opened this issue Jul 13, 2015 · 5 comments
Milestone

Comments

@ydahhrk
Copy link
Member

@ydahhrk ydahhrk commented Jul 13, 2015

This is going to be postponed until version 4.x because users likely expect this kind of change in major version releases.

Several things seem to buzz over people's heads. Here are some ideas:

  • depmod doesn't technically need to be called on every install, but the performance increase for not calling it isn't worth it being an extra step. In addition, its "optionalness" is not documented. There's really no reason why users should ever worry about this. Therefore, make modules_install should call depmod automatically. Done. The new target make install is equivalent to make modules_install && depmod. Both are available now.
  • Some users forget to install the userspace application and then wonder why their commands fail. All four binaries (stateless/stateful userspace/kernelspace) should be compiled and installed out of a single make && sudo make install kick, and the documentation should reflect this.
    Of course, the option to compile each binary separately should still exist.
  • I have the nagging impression the solution to #159 removed the need to turn offloads off. We need to confirm this and purge this off-putting step from people's lives. Offloads are still needed off.

Additional ideas welcomed.

@ydahhrk ydahhrk added this to the 4.0.0 milestone Jul 13, 2015
@Namsep

This comment has been minimized.

Copy link

@Namsep Namsep commented Jul 13, 2015

Maybe some sort of install script that gives you options (full SIIT-DC) or home NAT64 /DNS 64 gateway?

@ydahhrk

This comment has been minimized.

Copy link
Member Author

@ydahhrk ydahhrk commented Jul 13, 2015

Maybe some sort of install script that gives you options (full SIIT-DC) or home NAT64 /DNS 64 gateway?

I imagine it would be simple for a script to apply the stuff needed to make this happen, but the fact other nodes also need to be configured (for the whole thing to work) confuses me.

(edit: when I say "other nodes need to be configured" I mean setting up default gateway
and similar network bureaucracy.)

So just to check scope:

Do you expect this script to get the translating machine running only, or do you have in mind something that fixes the entire network?

@ydahhrk

This comment has been minimized.

Copy link
Member Author

@ydahhrk ydahhrk commented Jul 13, 2015

I imagine it would be simple for a script to apply the stuff needed to make this happen, but the fact other nodes also need to be configured (for the whole thing to work) confuses me.

In addition to a DNS64, we could also install a DHCP server.
Hmmm. Interesting.

@ydahhrk

This comment has been minimized.

Copy link
Member Author

@ydahhrk ydahhrk commented Sep 9, 2015

Another one:

  • make install should be an alias for make modules_install && depmod. Done.
ydahhrk added a commit that referenced this issue Sep 10, 2015
 features.

The changes are backwards-compatible anyway, so it's alright to release in version 3.4.
ydahhrk added a commit that referenced this issue Aug 28, 2017
The intent is simply to trim some structural fat the project has
been collecting with the refactors.

The project is completely unstable now; all paths are outdated in
an effort to keep the files the same to ensure proper future
tracking by git.

First step towards hopefully nailing #163.
ydahhrk added a commit that referenced this issue Oct 9, 2018
I got carried away and ended up streamlining the entire directory
tree as part of the build system refactor.

Fixes the second bullet from #163.

Also deletes a bunch of dead code.
@ydahhrk ydahhrk modified the milestones: 4.0.0, 3.6.0 Nov 23, 2018
@ydahhrk ydahhrk modified the milestones: 3.6.0, 4.0.0 Jan 9, 2019
@ydahhrk

This comment has been minimized.

Copy link
Member Author

@ydahhrk ydahhrk commented Jan 17, 2019

Honestly, at this point I think that packages (#243) are as far as we'll go.

Realistically speaking, providing scripts to build an entire translation environment is too far from the scope of the project, too ambitious given our resources and would require too many assumptions regarding the user's needs.

If a significant portion of the community wants it, then it's probably better if somebody else provides it as a separate project.

I'd like to cancel that for now. The rest is already finished and released in Jool 4.0.0.

@ydahhrk ydahhrk closed this Jan 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.