Re: [gentoo-dev] Re: GNU userland and binary package (WAS: RFC: sh versionator.eclass)

2007-10-09 Thread Natanael Copa
On Mon, 2007-10-08 at 20:25 +0100, Steve Long wrote:
 Natanael Copa wrote:

 If you're that motivated why not just start hacking on binary support in
 portage/pkgcore/paludis? There's always open bugs.

I think I did contribute with some patches for qmerge in portage-utils.

Unfortunally, its pretty difficult to make a lightweight C (language)
only binary installer without having at least the eclasses and GNU
tools.

It kind of defeat the idea of having a lightweight binary only runtime
environment. (lightweight means busybox - which give you most of the
basic GNU tools, linux-utils, wget, shell, http server and much more for
the size of bash only)

  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.

To properly install a prebuilt binary packages you need the pkg_* funcs
in the ebuild.

 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. 

We already do different for init.d scripts (which is great!) , but sure,
I get the point.

 For every market except embedded, which we've discussed
 already, BASH is not a major issue: nor are the other tools mentioned.

I happen to do embedded.

  
  Alternative C is what I do today.
  
 Sounds rough :)

Thats why I'm interested in alternatives.

 (I really would recommend #pkgcore as well as there is several years of work
 to do with binpkgs in that.)

So far no packagemanager using the portage stuff (eclasses) are not even
close to compete in size for binary only installs. Closest is
portage-utils's qmerge but it would need atleast the eclasses and bash
which would atleast double the size in comparison what I do today.

Looks like i will need to continue do my own stuff.

Thanks for you time!

 Standardising on a certain subset of base GNU tools seems like a good idea
 to me too.

-nc

-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Re: GNU userland and binary package (WAS: RFC: sh versionator.eclass)

2007-10-08 Thread Steve Long
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