On 10/8/07, Natanael Copa <[EMAIL PROTECTED]> 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 > > > > > > > > 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 -- [EMAIL PROTECTED] mailing list
