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

[Alec Warner]

On 10/8/07, Natanael Copa <natanael.copa@×××××.com> wrote:
> On Mon, 2007-10-08 at 06:52 -0700, Alec Warner wrote:
> > On 10/8/07, Natanael Copa <natanael.copa@×××××.com> 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
> > > >
> > > > 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.  ;)
> > > >
> > > >                                               -Joe
> > >
> > > 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.
> >
> > 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?
>
> Those pops up to my mind:
>
> A. move the pkg_* functions out of the ebuild to a separate file. Those
> have a subset of the EAPI and needs to be posix compliant.

This is just rife with complications, IMHO.  Two files per ebuild
revision?  Shared pre/post functions?  Extra manifests, stats,
sourcing, bigger tree, inode requirements.  Probably not an easy sell
here.

>
> B. don't use GNU extensions in pkg_functions and have some way to export
> them (extract pkg_* functions from environment.bz2). Those can then be
> used by pre/post script in binary package manager.

This is your best bet, but again mandates are ineffective.  As you've
no doubt noticed with quoting, people will do whatever works and the
people who aim for odd targets like no GNU crap or sh compatability
are going to have to do the code reviews and encourage that sort of
thing.  Just saying 'pre/post functions must be POSIX compatable' will
get you nowhere.  The point here is to sell your idea to other
developers; if you can't sell it you may need to take it elsewhere.

>
> C. Binary package managers will need to write their own pre/post
> scripts

Good luck with this route; you may be able to write replacements for
most utilities but I bet the conversion would still fail on weird
constructs.

D.  Keep your own ebuilds.  Particularly for embedded you probably
aren't using a ton of them anyway and given a sufficient pool of
developers interested in POSIX compatible ebuilds you could probably
hammer out a posix-compliant embedded tree in short order.  I know
everyone hates option D; but I'm also kind of irritated by everyone
trying to push weird requirements on everyone else.  If you can't
convince the majority of developers to do thing X, you may end up
having to do it yourself; welcome to open source software ;)

-Alec
-- 
gentoo-dev@g.o mailing list