| 1 |
Shinkan wrote: |
| 2 |
> |
| 3 |
> |
| 4 |
> 2009/12/1 Mansour Moufid <mansourmoufid@×××××.com |
| 5 |
> <mailto:mansourmoufid@×××××.com>> |
| 6 |
> |
| 7 |
> |
| 8 |
> You really shouldn't unmerge Portage, but if you want to, it should be |
| 9 |
> the last step -- coming *after* emerge -uUDN world && emerge |
| 10 |
> --depclean && revdep-rebuild. After which you can safely rm -drf |
| 11 |
> /usr/portage. |
| 12 |
> |
| 13 |
> |
| 14 |
> I get the way you would do the things, but that's quite the same thing |
| 15 |
> that catalyst do behind the scene. |
| 16 |
> But it uses a cache system that avoid re-emerging too often. |
| 17 |
> That's chrooting a stage3, emerging fancy features, then removing |
| 18 |
> others, all of this according to profiles. |
| 19 |
> I thing that's not very maintainable and that's error prone (because |
| 20 |
> you're not sure of what is unmerged, or what dependencies it could break). |
| 21 |
|
| 22 |
I haven't looked, but this isn't the way I understand Catalyst to work? |
| 23 |
|
| 24 |
What it should be doing is exactly what you would do if you wrote your |
| 25 |
own scripts (It's basically just a fancy wrapper). So look at the |
| 26 |
TinyGentoo instructions: http://en.gentoo-wiki.com/wiki/TinyGentoo and |
| 27 |
this gives you the basic principles |
| 28 |
|
| 29 |
I use a kind of similar process to build my builds. I use a chroot as |
| 30 |
the build system (basically just a roughly right stage4 build), then I |
| 31 |
chroot into that and build packages for everything that I need, then I |
| 32 |
install all the packages into some build directory and that becomes the |
| 33 |
new installation. This means that the destination doesn't need portage |
| 34 |
or gcc, etc (it's a very small and bare installation). You can also |
| 35 |
build packages to distribute with qpkg, etc. |
| 36 |
|
| 37 |
Also see alpine linux? |
| 38 |
|
| 39 |
> I'm interrested if there's a magic command to unmerge & clean every |
| 40 |
> dev related things once system is built. |
| 41 |
|
| 42 |
Sure - just "emerge -C yourstuff" and it's gone. You can easily get a |
| 43 |
list of packages that were installed, you just need to know which ones |
| 44 |
you want to remove? I personally build mine the other way and install |
| 45 |
only the stuff I need |
| 46 |
|
| 47 |
What I *expect* catalyst to do is to build a stage1-4 build environment, |
| 48 |
then use that stage4 build environment to build another stage1-4 |
| 49 |
distribution where each stage builds incrementally? Never used |
| 50 |
catalyst, but that's what I would expect to happen. The logic being |
| 51 |
that you first build the build environment, then use the build |
| 52 |
environment to build the final distribution. You could jump straight in |
| 53 |
and script all the steps directly yourself if you dont need the |
| 54 |
flexibility of catalyst? |
| 55 |
|
| 56 |
> ONE OFF-TOPIC MORE GENERAL QUESTION : |
| 57 |
> Is there a gentoo hardened toolchain with SSP and PIE BEFORE gcc 4 ? |
| 58 |
|
| 59 |
Actually that's the gcc3.4.6 which was stable only a few weeks ago. |
| 60 |
However, as has been mentioned it's not the same SSP as the new GCC4.4. |
| 61 |
|
| 62 |
There is a hardened overlay for gcc4.4 and I'm using this right now in |
| 63 |
conjunction with uclibc and I have to say it's working very nicely with |
| 64 |
fairly few workarounds needed (Python and sandbox mainly). I'm actually |
| 65 |
unsure why it's not already migrated to gentoo package masked, however, |
| 66 |
I would suggest you base any new work on that overlay if you are |
| 67 |
starting now |
| 68 |
|
| 69 |
Good luck |
| 70 |
|
| 71 |
Ed W |
Archives