Re: [gentoo-dev] GNU userland and binary package (WAS: RFC: sh versionator.eclass)
On Wed, 2007-10-10 at 20:03 -0700, Alec Warner wrote: 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. This is what I'm preaching, but for the whole ebuild not just the pre/post functions. It's a tough crowd as everyone's a zealot with their own favourite must have tools + the territorial crap which rears it's ugly head from time to time. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GNU userland and binary package (WAS: RFC: sh versionator.eclass)
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
[gentoo-dev] GNU userland and binary package (WAS: RFC: sh versionator.eclass)
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. -nc -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GNU userland and binary package (WAS: RFC: sh versionator.eclass)
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. -Alec -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] GNU userland and binary package (WAS: RFC: sh versionator.eclass)
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. 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. C. Binary package managers will need to write their own pre/post scripts. Any other alternatives? Comments? Alternative C is what I do today. -nc -Alec -- [EMAIL PROTECTED] mailing list
