-
Notifications
You must be signed in to change notification settings - Fork 68
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
Installing into / instead of /opt #443
Comments
In KEEP/butch_template_configure_cached.txt, there is this line:
That looks like it. I was wondering though, if that variable butch_do_custom_destdir could be made available in the 'config' file, and in KEEP/butch_template_configure_cached.txt have a test: Would that be do-able, or is there more to it? |
do you have any comparison results, or is this just a "feeling" ?
yes, that is the intended way. it was never tested though so there may be some gotchas (or packages with hardcoded assumptions) that would need to be fixed, however i think those should be easy to fix and few of them. |
There were some posts that I read on the old mail-list, that quantified the speed penalty of Sabotage's symlinks, though it was commented that it would not be noticeable. A hard-link is just a directory entry, whereas a soft link has its own inode. Meaning that the hard link is smaller. More explanation here: Regarding the installing to /, I'll give it a go, see what recipes give trouble. |
i pushed a commit that makes butch_do_custom_destdir overridable, so you can play with it: 23ecfa3 . |
Why have you removed this line, in the case of butch_do_custom_destdir=false: |
the variable will never be used when butch_do_custom_destdir is false due to the early exit i added (before echo "post buildscript phase...") |
Trying it now, with "export butch_do_custom_destdir=false" in config , running "./build-stage0":
It isn't flagging an error, but build_gcc3.log has this at the end:
build_sabotage-core.log has this:
|
I inserted a line into sabotage-core recipe:
Getting a bit further this time:
build_stage0-musl.log has this:
So, the problem goes back to gcc3. |
It looks like recipe for gcc3 needs this also inserted near the end: |
OK, running "./build-stage0", with "butch_install_dir=/" in butch_template_configure_cached.txt. No, stage0-musl fails with the same error. gcc has failed moves, like this: |
In butch_template_configure_cached.txt, perhaps it is more logical to leave:
...no, that's not right either, it is going to end up with lots of "make DESTDIR= install" |
Got it! I made what seems to me to be a very logical change to butch_template-configure_cached.txt: ...I don't know how to submit a pull request for an individual commit! Running "./build-stage0", it still fails, but gets much further. Unfortunately, I have other things to do right now, will get back to this in the afternoon. |
I am able to get back on my computer for a short time, looking why jobflow failed: $R/bin/musl-gcc has this in it:
What generates that file? It isn't what is supposed to be there. The recipe for musl copies $K/musl-gcc to $R/bin, which is a very different file. |
Looking at build_jobflow.log, it seems to start off executing musl-gcc ok:
...then musl-gcc self-destructs. |
OK, found the cause. Recipe stage0-musl is assuming installation of musl is in /opt. I have modified recipe stage0-musl, running "./build-stage0" now... |
Yes, another one bites the dust! I still haven't figured out how to submit to you a pull request for my individual commits. |
There is a show-stopper in stage1. The 'config' file worked in stage0, I had this in it: However, that doesn't carry over to the 'config' file in the build directory. Whereabouts is that 'config' file created? |
Ah ha! Have nailed that bug too. Stage1 should compile and install correctly now. Testing... Yep, packages in stage1 now installing correctly. Here is my fix: |
Yikes! The recipe for kbd wiped out the entire /bin directory. OK, kbd has compiled, stage1 completed zero errors. Here is the fix for kbd: There is a problem though. Previously, only a cut-down "slitaz_set" was installed. Now, we have the whole lot. |
Ha ha, have finished compiling stage1, all is well, except I just noticed folder $R/x86_64-unknown-linux-gnu. That would be a gcc thing? Where is it supposed to go? Packages are still compiling with it there. $R/x86_64-unknown-linux-gnu/bin has ar, as, ld, etc. |
Compiled about 60 packages so far, looking good! EDIT: |
Firefox is now compiling. I installed my Sabotage build on a USB stick and booted it. Running great. I'm on another laptop right now, as the flash stick currently doesn't have a browser. Gets on the Internet OK though. This has been an extremely interesting exercise. I wanted to build a host system from Sabotage, with everything installed to /. Then running in that host system, compile lots more packages, installed to /opt, and create binary tarballs. This is so others, running the same host system, can use the Puppy Package Manager to install them (instead of building from source with butch) -- but that's another topic. Lots of interesting ideas to play with. I still haven't uploaded the latest package fixes. EDIT: |
I read somewhere, someone asking this question, maybe it was on the mail-list. The reply was, yes, it can be done.
Is that still the case? If If so, for the default set to install into /, what variable would I have to change?
Perhaps some recipes are hard-coded to install into /opt? -- when I first started writing recipes, I am guilty of that. But then, that should be ok, some packages can be installed into /opt, even though the default is /.
Just an extra note: I wrote some code that converts all of the symlinks into /opt, to hard-links. And symlinks-to-symlinks changed to symlink to the local hard-link -- for example /bin/ls was a symlink to /opt/busybox/bin/ls, now becomes symlink to /bin/busybox.
The result is faster operation, smaller size (as hard-links are smaller than symlinks), and looking at the file with a graphical file manager, it looks like a normal filesystem, instead of a window full of symlinks.
In fact, after doing that, most of /opt can be deleted, if desired for any reason. Although there is /opt/busybox/bin/busybox and /bin/busybox, they are hard-links to the same inode, the same file, and deleting one of them does not delete the file. Both hard-links have to be deleted.
...this is actually a very roundabout way of ending up with a "normal" filesystem, with most pkgs in /.
The text was updated successfully, but these errors were encountered: