| 1 |
On Thu, 10 Jun 2004, Mike Frysinger wrote: |
| 2 |
|
| 3 |
> > The current approach does not allow replacement of some/all of the |
| 4 |
> > packages for other platforms, my proposal would be to use only virtual |
| 5 |
> > names for build/system and define these differently for glibc/uclibc (and |
| 6 |
> > maybe others). |
| 7 |
> |
| 8 |
> simple answer, no |
| 9 |
> that's the point of the stackable profiles ... you can add/delete packages |
| 10 |
> from parent profiles in your sub-profile |
| 11 |
> |
| 12 |
> the changes you list are just not worth the gained cruft in the standard |
| 13 |
> profiles ... in your embeded profile, setup a virtual file where busybox |
| 14 |
> provides all the stuff you want it to |
| 15 |
|
| 16 |
how to handle for ex. tar's case: |
| 17 |
tar requires: app-arch/gzip, app-arch/bzip2, app-arch/ncompress |
| 18 |
|
| 19 |
Now, I know that let's say tar can't be replaced, because the busybox |
| 20 |
version is not good enough (take it as the main package) but |
| 21 |
gzip/bzip2/ncompress could be. How should this be handled? |
| 22 |
|
| 23 |
The one way I proposed, was to use virtual/gzip and so on, the other, |
| 24 |
"non-destructive" way would be to change tar's requirements to |
| 25 |
!uclibc? ( app-arch/gzip ) ... |
| 26 |
|
| 27 |
Apropos gzip: why are the virtuals not used that already exist (there is a |
| 28 |
virtual/gzip also virtual/dev-manager instead of sys-fs/devfsd) |
| 29 |
|
| 30 |
> |
| 31 |
> > 1. the gettext package is always required for emerge system (but this in |
| 32 |
> > most cases only an nls requirement), building w/o nls does not/should not |
| 33 |
> > need gettext (some packages need patches for this) |
| 34 |
> |
| 35 |
> yes but when patching configure.in and related files and re-running |
| 36 |
> `autoconf`, the process will fail if the file refers to NLS stuff and |
| 37 |
> gettext, not being installed on the system, did not provide all the m4 and |
| 38 |
> related files |
| 39 |
|
| 40 |
ok, I understand this, but for the build system itself autoconf is not |
| 41 |
present, so can't run it either, and have to provide the result of |
| 42 |
autoconf as patch, so it should not be in the packages.build file at all |
| 43 |
|
| 44 |
> > 2. groff requires c++ (and is used by man), if an embedded system does not |
| 45 |
> > 3. uclibc does not support pam, so the package pam/pam-login/pwdb should |
| 46 |
> > snip |
| 47 |
> |
| 48 |
> see above about adding/deleting packages from the profile |
| 49 |
|
| 50 |
do you mean using |
| 51 |
-<package> |
| 52 |
This is supposed to work only w/ the stackable structure, right? |
| 53 |
|
| 54 |
The dependencies are really my concern, as described for the tar case, not |
| 55 |
the single packages themselves. |
| 56 |
|
| 57 |
What would you propose to do for another libc (like uclibc), start w/ a |
| 58 |
new tree, lets call it uclibc, create the packages[.build] virtual files |
| 59 |
w/o a parent file, or w/ a parent removing the non-required packages? |
| 60 |
|
| 61 |
Peter |
| 62 |
|
| 63 |
-- |
| 64 |
Peter S. Mazinger <ps dot m at gmx dot net> ID: 0xA5F059F2 |
| 65 |
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2 |
| 66 |
|
| 67 |
|
| 68 |
____________________________________________________________________ |
| 69 |
Miert fizetsz az internetert? Korlatlan, ingyenes internet hozzaferes a FreeStarttol. |
| 70 |
Probald ki most! http://www.freestart.hu |
| 71 |
|
| 72 |
-- |
| 73 |
gentoo-embedded@g.o mailing list |
Archives