| 1 |
On Mon, 2007-10-08 at 20:25 +0100, Steve Long wrote: |
| 2 |
> Natanael Copa wrote: |
| 3 |
|
| 4 |
> If you're that motivated why not just start hacking on binary support in |
| 5 |
> portage/pkgcore/paludis? There's always open bugs. |
| 6 |
|
| 7 |
I think I did contribute with some patches for qmerge in portage-utils. |
| 8 |
|
| 9 |
Unfortunally, its pretty difficult to make a lightweight C (language) |
| 10 |
only binary installer without having at least the eclasses and GNU |
| 11 |
tools. |
| 12 |
|
| 13 |
It kind of defeat the idea of having a lightweight binary only runtime |
| 14 |
environment. (lightweight means busybox - which give you most of the |
| 15 |
basic GNU tools, linux-utils, wget, shell, http server and much more for |
| 16 |
the size of bash only) |
| 17 |
|
| 18 |
> >> Your own binary only package manager would still need to provide |
| 19 |
> >> Option #2; ie you need to have GNU tools installed to process the |
| 20 |
> >> binary packages. pkg_* functions could still have GNU stuff in them |
| 21 |
> >> and those still get run during a binary package install. |
| 22 |
> > |
| 23 |
> > If we would like to be able to do binary installs without the GNU tools, |
| 24 |
> > what alternatives do we have? |
| 25 |
> > |
| 26 |
> <snip stuff that all takes a lot of effort for zero end-user gain> |
| 27 |
> |
| 28 |
> > Any other alternatives? |
| 29 |
> > |
| 30 |
> > Comments? |
| 31 |
> > |
| 32 |
> I'd just specify BASH (as I don't see the point in making the distinction as |
| 33 |
> it only applies to build machines) and coreutils/findutils etc. |
| 34 |
|
| 35 |
To properly install a prebuilt binary packages you need the pkg_* funcs |
| 36 |
in the ebuild. |
| 37 |
|
| 38 |
> Asking everyone to switch coding style for certain functions, just to |
| 39 |
> support the stuff that Gentoo was designed to do from the beginning, seems |
| 40 |
> counter-productive. |
| 41 |
|
| 42 |
We already do different for init.d scripts (which is great!) , but sure, |
| 43 |
I get the point. |
| 44 |
|
| 45 |
> For every market except embedded, which we've discussed |
| 46 |
> already, BASH is not a major issue: nor are the other tools mentioned. |
| 47 |
|
| 48 |
I happen to do embedded. |
| 49 |
|
| 50 |
> > |
| 51 |
> > Alternative C is what I do today. |
| 52 |
> > |
| 53 |
> Sounds rough :) |
| 54 |
|
| 55 |
Thats why I'm interested in alternatives. |
| 56 |
|
| 57 |
> (I really would recommend #pkgcore as well as there is several years of work |
| 58 |
> to do with binpkgs in that.) |
| 59 |
|
| 60 |
So far no packagemanager using the portage stuff (eclasses) are not even |
| 61 |
close to compete in size for binary only installs. Closest is |
| 62 |
portage-utils's qmerge but it would need atleast the eclasses and bash |
| 63 |
which would atleast double the size in comparison what I do today. |
| 64 |
|
| 65 |
Looks like i will need to continue do my own stuff. |
| 66 |
|
| 67 |
Thanks for you time! |
| 68 |
|
| 69 |
> Standardising on a certain subset of base GNU tools seems like a good idea |
| 70 |
> to me too. |
| 71 |
|
| 72 |
-nc |
| 73 |
|
| 74 |
-- |
| 75 |
gentoo-dev@g.o mailing list |
Archives