Natanael Copa wrote:
On Mon, 2007-10-08 at 06:52 -0700, Alec Warner wrote:
On 10/8/07, Natanael Copa [EMAIL PROTECTED] wrote:
On Sun, 2007-10-07 at 21:26 -0600, Joe Peterson wrote:
Mike Frysinger wrote:
Fabian has summed it up nicely, thanks. i could care less what
your userland is outside of the ebuild environment since it doesnt
matter to ebuild
writers. you want a deficient runtime environment, more power to
you, but
forcing that environment onto ebuild developers is not acceptable.
off the top of my head, i'd like to see GNU find/xargs added to the
ebuild environment.
Mike, exactly as I said. That's option #2, and I think it could be a
great solution. As for deficient, well, that's in the eye of the
beholder. ;)
++ on the general idea: GNU sed, grep, awk, ed and find get my vote (as well
as BASH ofc.) (I don't /think/ you need xargs anymore with find .. -exec.)
Question, if you go for #2. Does that mean you will need all the
required GNU userland to do binary only installs?
It would be highly desireable to be able to do binary installs (write
your own binary only package manager) without depending on all the GNU
stuff needed to compile the packages.
Well all you're talking about is BASH and a few others on the machine that
builds the binaries afaict. I don't see that as a major imposition. You can
then package for downstream using whatever you like.
If you're that motivated why not just start hacking on binary support in
portage/pkgcore/paludis? There's always open bugs.
Your own binary only package manager would still need to provide
Option #2; ie you need to have GNU tools installed to process the
binary packages. pkg_* functions could still have GNU stuff in them
and those still get run during a binary package install.
If we would like to be able to do binary installs without the GNU tools,
what alternatives do we have?
snip stuff that all takes a lot of effort for zero end-user gain
Any other alternatives?
Comments?
I'd just specify BASH (as I don't see the point in making the distinction as
it only applies to build machines) and coreutils/findutils etc.
Asking everyone to switch coding style for certain functions, just to
support the stuff that Gentoo was designed to do from the beginning, seems
counter-productive. For every market except embedded, which we've discussed
already, BASH is not a major issue: nor are the other tools mentioned.
Alternative C is what I do today.
Sounds rough :)
(I really would recommend #pkgcore as well as there is several years of work
to do with binpkgs in that.)
Standardising on a certain subset of base GNU tools seems like a good idea
to me too.
--
[EMAIL PROTECTED] mailing list