| 1 |
On Fri, Apr 23, 2004 at 11:58:42AM -0400, Paul Smith wrote: |
| 2 |
> %% Jason Stubbs <jstubbs@g.o> writes: |
| 3 |
> |
| 4 |
> >> However, the problem of the current handling of DEPEND vs. RDEPEND |
| 5 |
> >> is not so simple to resolve. It looks like DEPEND and RDEPEND are |
| 6 |
> >> targeted at a very different scenario than the one I outline above. |
| 7 |
> |
| 8 |
> js> It's targeted at embedded systems and the like where you want to |
| 9 |
> js> be very specific about what you want to install. |
| 10 |
> |
| 11 |
> Mm. But of course, this will only work if your embedded system just |
| 12 |
> happens to be the same architecture as your build system... which I |
| 13 |
> think is not a good restriction to make. |
| 14 |
> |
| 15 |
|
| 16 |
I still don't see how `ROOT=/tmp/foo emerge blah` doesn't solve your problem. |
| 17 |
|
| 18 |
> I think a better solution to the "building an embedded system" issue |
| 19 |
> would be having some kind of locally-defined "final step" that extracts |
| 20 |
> the specific bits you want from the ROOT image and constructs the |
| 21 |
> embedded image from that. It could take advantage of the ROOT Portage |
| 22 |
> database files such as CONTENTS, etc. to figure out what files need to |
| 23 |
> be installed, and even postprocess it to remove things like man pages or |
| 24 |
> documentation which is deemed unnecessary for an embedded system. It |
| 25 |
> seems like the ROOT image having its own Portage database, rather than |
| 26 |
> mixed in with the local system's database, could be extremely useful. |
| 27 |
> |
| 28 |
> This way you could much more easily get REAL control over the content of |
| 29 |
> the embedded image. |
| 30 |
> |
| 31 |
|
| 32 |
there is already embedded tools that have been around for months. I |
| 33 |
posted my own tool called submerge that created embedded system |
| 34 |
images(basically shell scripts) back in november. |
| 35 |
|
| 36 |
I then took what I wrote and ported similar functioning module to |
| 37 |
catalyst. The patches have been merged and it should come out with |
| 38 |
the next catalyst release. |
| 39 |
|
| 40 |
with the embedded module you can: |
| 41 |
|
| 42 |
* specify what packages you want without dependancies |
| 43 |
* dictate use variables for your own image |
| 44 |
* prep the image into a filesystem of your choice(I use cramfs) |
| 45 |
* remove specified files and directories |
| 46 |
* remove specified packages that are not needed after compilation |
| 47 |
|
| 48 |
> Are there people using this feature right now? I'd be interested to |
| 49 |
> hear their opinions on the current behavior of ROOT. |
| 50 |
... |
| 51 |
> |
| 52 |
> I don't see how this solves the problem. First, the point is to allow |
| 53 |
> multiple "build" images, which this does not do, since it still uses the |
| 54 |
> local host for all DEPEND information. I don't want to have to update |
| 55 |
> (or downgrade!) my local host's installation of packages just to build |
| 56 |
> a ROOT with a different setup! Second, the ROOT is not a real Portage |
| 57 |
> system here: all the Portage database information, etc. is on the local |
| 58 |
> system. Third, this still won't work if the ROOT target is to be run on |
| 59 |
> different hardware than the build system. Etc. |
| 60 |
|
| 61 |
I don't understand what you mean by 'portage database information'. |
| 62 |
Maybe you could explain more, becuase I don't see any problems here |
| 63 |
either. |
| 64 |
|
| 65 |
Dave |
| 66 |
|
| 67 |
-- |
| 68 |
gentoo-dev@g.o mailing list |
Archives