[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/db: ChangeLog db-4.6.21.ebuild
On 18:58 Sun 04 Nov , Caleb Tennis (caleb) wrote:
1.1 sys-libs/db/db-4.6.21.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-libs/db/db-4.6.21.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-libs/db/db-4.6.21.ebuild?rev=1.1content-type=text/plain
for (( i=1 ; i=${PATCHNO} ; i++ )) ; do
for (( i=1 ; i=${PATCHNO} ; i++ ))
It reads strangely to mix ways of referencing variables like this. If
it's gonna be a C-style loop, then go all out:
for (( i=1 ; i=PATCHNO ; i++ ))
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] POSIX shell and portable
While I still have access to the [EMAIL PROTECTED] email, I'll respond here. On Mon, 2007-11-05 at 10:22 +0100, Michael Haubenwallner wrote: On Sat, 2007-11-03 at 00:47 +, Roy Marples wrote: As it seems too few people really accept your suggestion, I feel it's time for me to chime in too, although I don't know what exactly POSIX-sh standard defines. Agreed, but (speaking for alt/prefix): Alt/prefix is designed to (mainly) work without superuser access on the target machine, which may also be Solaris, AIX, HP-UX and the like. /bin/sh on such a machine is not POSIX-shell, but old bourne-shell (unfortunately with bugs often). And it is _impossible_ to have sysadmins to get /bin/sh a POSIX-Shell nor to have that bugs fixed. But yes, on most machines there is /bin/ksh, which IMHO is POSIX compliant (maybe also with non-fixable bugs). Although I do not know yet for which _installed_ scripts it'd be really useful to have them non-bash in alt/prefix, I appreciate the discussion. To see benefits for alt/prefix too, it _might_ require that discussion going from requiring /bin/sh being POSIX-sh towards being bourne-shell... Actually you missed the mark completely. Nothing in the tree itself specifies what shell to use - instead it's the package manager. So the PM on Gentoo/Linux/FreeBSD *could* be /bin/sh and on the systems where /bin/sh is not possible to change to a POSIX compliant shell then it can still use /bin/bash or wherever it's installed. This also applies to the userland tools. If the ebuild or eclass *has* to use the GNU variants then it should either adjust $PATH so that it finds them first, or it prefixes them all with g, like it does on Gentoo/FreeBSD. None of this is technically challenging in itself, it's just that the key people who would have to do the work to make this possible have already given a flat out no. It seems to me that you actually mean more FreeBSD-able or something, which is a high price to pay for a relatively small part of Gentoo as a whole. More embeddable. More BSDable. More Linuxable - bash isn't the only linux shell, there are plently of others. More (generic) unix-able. Exactly so :) Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] POSIX shell and portable
On Mon, 2007-11-05 at 10:13 +, Roy Marples wrote: While I still have access to the [EMAIL PROTECTED] email, I'll respond here. On Mon, 2007-11-05 at 10:22 +0100, Michael Haubenwallner wrote: On Sat, 2007-11-03 at 00:47 +, Roy Marples wrote: As it seems too few people really accept your suggestion, I feel it's time for me to chime in too, although I don't know what exactly POSIX-sh standard defines. Agreed, but (speaking for alt/prefix): Alt/prefix is designed to (mainly) work without superuser access on the target machine, which may also be Solaris, AIX, HP-UX and the like. /bin/sh on such a machine is not POSIX-shell, but old bourne-shell (unfortunately with bugs often). And it is _impossible_ to have sysadmins to get /bin/sh a POSIX-Shell nor to have that bugs fixed. But yes, on most machines there is /bin/ksh, which IMHO is POSIX compliant (maybe also with non-fixable bugs). Although I do not know yet for which _installed_ scripts it'd be really useful to have them non-bash in alt/prefix, I appreciate the discussion. To see benefits for alt/prefix too, it _might_ require that discussion going from requiring /bin/sh being POSIX-sh towards being bourne-shell... Actually you missed the mark completely. Nothing in the tree itself specifies what shell to use - instead it's the package manager. So the PM on Gentoo/Linux/FreeBSD *could* be /bin/sh and on the systems where /bin/sh is not possible to change to a POSIX compliant shell then it can still use /bin/bash or wherever it's installed. So have the installed scripts to not require bash is another topic ? Ok then: Given that we want to have the tree more generic unix-able: What is the benefit from having the tree being POSIX- but not bourne-shell compatible, so one still needs bash on Solaris/AIX/HP-UX ? Because I'd say those three are the biggest substitutes for unix, while I'd call *BSD and Linux just unix derivates (although with enhancements)... This also applies to the userland tools. If the ebuild or eclass *has* to use the GNU variants then it should either adjust $PATH so that it finds them first, or it prefixes them all with g, like it does on Gentoo/FreeBSD. None of this is technically challenging in itself, it's just that the key people who would have to do the work to make this possible have already given a flat out no. In the early prefix days I had some portage enhancement, providing a wrapper-function around all coreutils/findutils/diffutils/grep/others, trying to find a GNU implementation for them. And if not found, try to map some args to the native ones (xargs -r fex - although didn't work as shell-function). But then we decided to always provide USERLAND=GNU in prefix and this portage patch was thrown away. It seems to me that you actually mean more FreeBSD-able or something, which is a high price to pay for a relatively small part of Gentoo as a whole. More embeddable. More BSDable. More Linuxable - bash isn't the only linux shell, there are plently of others. More (generic) unix-able. Exactly so :) Not really as long as not being bourne shell compatible like autoconf's configure. I won't trust to have a POSIX shell like /bin/ksh everywhere, but /bin/sh only, which usually is just a bourne shell on unix. /haubi/ -- Michael Haubenwallner Gentoo on a different level -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sci-mathematics/mathomatic: ChangeLog mathomatic-12.7.9.ebuild
On Friday 02 November 2007 02:59:36 Donnie Berkholz wrote: Could you drop the icc USE flag? All you need to do is make sure this package respects CC, CFLAGS and LDFLAGS, and users can take care of the rest in make.conf. I never put it in and just left it alone as I don't use ICC. I have dropped it in the testing version but would rather leave the stable version alone. So if nobody objects it will go from the tree once I stabilise this version. Is this policy that we are getting rid of icc stuff now? I think kugelfang added it but didn't check to be honest. Just so I know when doing future bumps. Thanks, Marcus -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Global useflag for enabling visibility support
On E, 2007-11-05 at 16:19 +0100, Piotr Jaroszyński wrote: Hello, I think it's time to add a more general flag for enabling visibility support in packages as currently there is only a kde specific one (kdehiddenvisibility) and I don't think it makes sense to add a new one for each package that needs it. Why do they need it, is the question. If it's supported and stable, it should just be enabled, end of story, in my opinion. I believe it was optional in KDE due to it not being stable for some reason (either GCCs at the time were sketchy or their build system problems weren't smoothed out, I guess). I have just added a local visibility flag for paludis and that's also my candidate for the global one, but better names are welcome. Why not enable it by default and unconditionally (other than GCC version being used supporting it) in this specific case? -- Mart Raudsepp Gentoo Developer Mail: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
With Uberlord's retirement we should do the usual magic voodoo procedure to summon in the next-in-line member (which would be Jokey if i'm not mistaken). cheers, Wernfried -- Wernfried Haas (amne) - amne (at) gentoo.org Gentoo Forums - http://forums.gentoo.org forum-mods (at) gentoo.org #gentoo-forums (freenode) pgpJtMz7REaDO.pgp Description: PGP signature
Re: [gentoo-dev] Global useflag for enabling visibility support
Piotr Jaroszyński [EMAIL PROTECTED] writes: I think it's time to add a more general flag for enabling visibility support in packages as currently there is only a kde specific one (kdehiddenvisibility) and I don't think it makes sense to add a new one for each package that needs it. Some packages, such as mozilla-firefox, enable visibility support without the use of a USE flag. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-firewall/ipset: ChangeLog metadata.xml ipset-2.3.0.20070828.ebuild
On 14:23 Mon 05 Nov , Peter Volkov (pva) wrote:
1.1 net-firewall/ipset/ipset-2.3.0.20070828.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-firewall/ipset/ipset-2.3.0.20070828.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-firewall/ipset/ipset-2.3.0.20070828.ebuild?rev=1.1content-type=text/plain
src_defs() {
# these are used in both of src_compile and src_install
myconf=${myconf} PREFIX=
myconf=${myconf} LIBDIR=/lib
Should this be get_libdir()?
Also seems like instead of having a function to do this, you could just
define the variables once in pkg_setup() or src_compile() as globals.
pkg_config() {
cd ${ROOT}${PORTAGE_TMPDIR}
mkdir patch-o-matic-ng
cd patch-o-matic-ng
IPTVERINS=`echo $(best_version net-firewall/iptables) | \
sed -n
's:^[^/]*/[[:alpha:]]*-\([0-9]\+\([.][0-9]\+\)*[a-z]\?\(_\(pre\|p\|beta\|alpha\|rc\)[0-9]*\)*\)\(-r[0-9]\+\)\?$:\1:p'`
einfo Unpacking patch-o-matic-ng-${POM_PV}
tar -jxf ${DISTDIR}/patch-o-matic-ng-${POM_PV}.tar.bz2 || \
die Unable to unpack
patch-o-matic-ng-${POM_PV}
einfo Unpacking iptables-${IPTVERINS}
tar -jxf ${DISTDIR}/iptables-${IPTVERINS}.tar.bz2 || \
die Unable to unpack
iptables-${IPTVERINS}.tar.bz2
Could you just call unpack() here?
einfo Enter path to your kernel sources, relative to ${ROOT}
echo -n [/usr/src/linux]:
read K_DIR
[ ${ROOT}${K_DIR} == / ] K_DIR=${ROOT}/usr/src/linux
/usr/src/linux should be what's used here, and if they want to change
the kernel to affect, they should change where the symlink points
instead of having a secondary config mechanism.
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/paludis: ChangeLog paludis-0.26.0_alpha3.ebuild
On 14:58 Mon 05 Nov , Piotr Jaroszynski (peper) wrote:
1.1 sys-apps/paludis/paludis-0.26.0_alpha3.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/paludis/paludis-0.26.0_alpha3.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-apps/paludis/paludis-0.26.0_alpha3.ebuild?rev=1.1content-type=text/plain
create-paludis-user() {
enewgroup paludisbuild
enewuser paludisbuild -1 -1 /var/tmp/paludis paludisbuild
}
pkg_setup() {
replace-flags -Os -O2
create-paludis-user
}
pkg_preinst() {
create-paludis-user
}
Shouldn't need to create a user twice, and that quoting makes this a bit
harder to read than it needs to be.
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Global useflag for enabling visibility support
On Monday 05 November 2007, Mart Raudsepp wrote: On E, 2007-11-05 at 16:19 +0100, Piotr Jaroszyński wrote: Hello, I think it's time to add a more general flag for enabling visibility support in packages as currently there is only a kde specific one (kdehiddenvisibility) and I don't think it makes sense to add a new one for each package that needs it. Why do they need it, is the question. If it's supported and stable, it should just be enabled, end of story, in my opinion. I believe it was optional in KDE due to it not being stable for some reason (either GCCs at the time were sketchy or their build system problems weren't smoothed out, I guess). I have just added a local visibility flag for paludis and that's also my candidate for the global one, but better names are welcome. Why not enable it by default and unconditionally (other than GCC version being used supporting it) in this specific case? this sounds good to me too ... binding USE flags to compiler options is generally frowned upon and we should avoid it when possible. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] POSIX shell and portable
On Monday 05 November 2007, Michael Haubenwallner wrote: On Mon, 2007-11-05 at 10:13 +, Roy Marples wrote: While I still have access to the [EMAIL PROTECTED] email, I'll respond here. On Mon, 2007-11-05 at 10:22 +0100, Michael Haubenwallner wrote: On Sat, 2007-11-03 at 00:47 +, Roy Marples wrote: As it seems too few people really accept your suggestion, I feel it's time for me to chime in too, although I don't know what exactly POSIX-sh standard defines. Agreed, but (speaking for alt/prefix): Alt/prefix is designed to (mainly) work without superuser access on the target machine, which may also be Solaris, AIX, HP-UX and the like. /bin/sh on such a machine is not POSIX-shell, but old bourne-shell (unfortunately with bugs often). And it is _impossible_ to have sysadmins to get /bin/sh a POSIX-Shell nor to have that bugs fixed. But yes, on most machines there is /bin/ksh, which IMHO is POSIX compliant (maybe also with non-fixable bugs). Although I do not know yet for which _installed_ scripts it'd be really useful to have them non-bash in alt/prefix, I appreciate the discussion. To see benefits for alt/prefix too, it _might_ require that discussion going from requiring /bin/sh being POSIX-sh towards being bourne-shell... Actually you missed the mark completely. Nothing in the tree itself specifies what shell to use - instead it's the package manager. So the PM on Gentoo/Linux/FreeBSD *could* be /bin/sh and on the systems where /bin/sh is not possible to change to a POSIX compliant shell then it can still use /bin/bash or wherever it's installed. So have the installed scripts to not require bash is another topic ? yes, and generally that's a baked topic. if your script is /bin/sh, then it must be POSIX compliant. if your script is /bin/bash, then you're encouraged to convert it to POSIX /bin/sh. but this is because the *runtime* environment is generally a lot more restricted than that of the *buildtime* environment. runtime implies a lot leaner requirements (think binary-only systems, embedded systems, production systems, etc...) than that of a development system (which requires everything in order to compile). Ok then: Given that we want to have the tree more generic unix-able: What is the benefit from having the tree being POSIX- but not bourne-shell compatible, so one still needs bash on Solaris/AIX/HP-UX ? Because I'd say those three are the biggest substitutes for unix, while I'd call *BSD and Linux just unix derivates (although with enhancements)... we want the installed environment to be portable, not the build environment. i do not see any benefit from forcing the build environment to be pure POSIX compliant and i see many many detrimental problems. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] POSIX shell and portable
On Mon, 2007-11-05 at 14:21 +0100, Michael Haubenwallner wrote: Actually you missed the mark completely. Nothing in the tree itself specifies what shell to use - instead it's the package manager. So the PM on Gentoo/Linux/FreeBSD *could* be /bin/sh and on the systems where /bin/sh is not possible to change to a POSIX compliant shell then it can still use /bin/bash or wherever it's installed. So have the installed scripts to not require bash is another topic ? No, it's a valid topic. Either the profile could hook src_unpack or the ebuild could call a function to do this sed -e '1 s,^#!/bin/sh,#!/path/to/bash,' Either for all files in CONTENTS or all arguments passed. Ok then: Given that we want to have the tree more generic unix-able: What is the benefit from having the tree being POSIX- but not bourne-shell compatible, so one still needs bash on Solaris/AIX/HP-UX ? Because I'd say those three are the biggest substitutes for unix, while I'd call *BSD and Linux just unix derivates (although with enhancements)... The benefit is that we're not locked into any one toolset. This makes development of the tree more attractive to non Linux developers I would say. This also applies to the userland tools. If the ebuild or eclass *has* to use the GNU variants then it should either adjust $PATH so that it finds them first, or it prefixes them all with g, like it does on Gentoo/FreeBSD. None of this is technically challenging in itself, it's just that the key people who would have to do the work to make this possible have already given a flat out no. In the early prefix days I had some portage enhancement, providing a wrapper-function around all coreutils/findutils/diffutils/grep/others, trying to find a GNU implementation for them. And if not found, try to map some args to the native ones (xargs -r fex - although didn't work as shell-function). But then we decided to always provide USERLAND=GNU in prefix and this portage patch was thrown away. I dislike wrappers. The maintainers of revdep-rebuild say the same thing and I'm sure others would as well. An alternative would be to say have a list of ebuilds that don't require the GNU toolset (via an eclass or the ebuild itself) in a profile and slowly update the ebuilds and the lists when we can make them work with the desired userlands. If it requires gratuitous use of extensions then maybe the package itself should be patched upstream instead of us having to write overly complex ebuilds. Probably not the best idea for this, but workable. More (generic) unix-able. Exactly so :) Not really as long as not being bourne shell compatible like autoconf's configure. I won't trust to have a POSIX shell like /bin/ksh everywhere, but /bin/sh only, which usually is just a bourne shell on unix. As I said above, portage could change this. Think of it as an #ifdef :) Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] POSIX shell and portable
On 05-11-2007 20:32:09 +, Roy Marples wrote: More (generic) unix-able. Exactly so :) Not really as long as not being bourne shell compatible like autoconf's configure. I won't trust to have a POSIX shell like /bin/ksh everywhere, but /bin/sh only, which usually is just a bourne shell on unix. As I said above, portage could change this. Think of it as an #ifdef :) We already (have to) do this, and it is not as trivial as you think. Though, as Mike pointed out, we sort of all agree that scripts outside of portage should be POSIX sh. -- Fabian Groffen Gentoo on a different level -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] POSIX shell and portable
On Monday 05 November 2007, Roy Marples wrote: On Mon, 2007-11-05 at 14:21 +0100, Michael Haubenwallner wrote: Actually you missed the mark completely. Nothing in the tree itself specifies what shell to use - instead it's the package manager. So the PM on Gentoo/Linux/FreeBSD *could* be /bin/sh and on the systems where /bin/sh is not possible to change to a POSIX compliant shell then it can still use /bin/bash or wherever it's installed. So have the installed scripts to not require bash is another topic ? No, it's a valid topic. he didnt say it was invalid, just a different topic Either the profile could hook src_unpack or the ebuild could call a function to do this sed -e '1 s,^#!/bin/sh,#!/path/to/bash,' fix the packages i say -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] POSIX shell and portable
On Mon, 2007-11-05 at 16:21 -0400, Mike Frysinger wrote: we want the installed environment to be portable, not the build environment. i do not see any benefit from forcing the build environment to be pure POSIX compliant and i see many many detrimental problems. Oh I don't know. Imagine how cool it would be for starting a new port. 1) Install PM 2) Wang on a portage tree 3) emerge ready to go Obviously it's not quite that simple as portage requires python and pkgcore require python, paludis requires tr1-whatever libs - but that's the restriction of the PM used. Maybe one day Gentoo will have a PM that doesn't require any of that and is just written in C and sh, using POSIX libc where it can. But enough pipe dreaming :) Thanks Roy -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last Rites - October 29th - November 5th, 2007
Attached are the packages scheduled for removal this week, extended one day to include the treecleaners cleanup. -- looks like christmas at fifty-five degrees this latitude weekens my knees EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 (0xF9A40662) dev-java/cairo-javaPetteri Räty [EMAIL PROTECTED] 04 Dec 2007 dev-java/glib-java Petteri Räty [EMAIL PROTECTED] 04 Dec 2007 dev-java/libgconf-java Petteri Räty [EMAIL PROTECTED] 04 Dec 2007 dev-java/libglade-java Petteri Räty [EMAIL PROTECTED] 04 Dec 2007 dev-java/libgnome-java Petteri Räty [EMAIL PROTECTED] 04 Dec 2007 dev-java/libgtk-java Petteri Räty [EMAIL PROTECTED] 04 Dec 2007 dev-java/libvte-java Petteri Räty [EMAIL PROTECTED] 04 Dec 2007 dev-java/sun-jaf-bin Petteri Räty [EMAIL PROTECTED] 04 Dec 2007 dev-lang/ghc-bin Duncan Coutts [EMAIL PROTECTED] 05 Dec 2007 app-editors/beaver Samuli Suominen [EMAIL PROTECTED]04 Jan 2008 app-portage/portagemaster Samuli Suominen [EMAIL PROTECTED]04 Jan 2008 app-vim/hgcommand Samuli Suominen [EMAIL PROTECTED]04 Jan 2008 app-vim/hgmenu Samuli Suominen [EMAIL PROTECTED]04 Jan 2008 dev-db/dbdesigner Samuli Suominen [EMAIL PROTECTED]04 Jan 2008 mail-client/elmo Samuli Suominen [EMAIL PROTECTED]04 Jan 2008 mail-client/sylpheed-claws Samuli Suominen [EMAIL PROTECTED]04 Jan 2008 mail-filter/popfileSamuli Suominen [EMAIL PROTECTED]04 Jan 2008 media-radio/ktrack Samuli Suominen [EMAIL PROTECTED]04 Jan 2008 net-analyzer/snmpmon Samuli Suominen [EMAIL PROTECTED]04 Jan 2008 net-im/jit Samuli Suominen [EMAIL PROTECTED]04 Jan 2008 net-im/jud Samuli Suominen [EMAIL PROTECTED]04 Jan 2008 sys-apps/discover-data Samuli Suominen [EMAIL PROTECTED]04 Jan 2008 sys-apps/discover Samuli Suominen [EMAIL PROTECTED]04 Jan 2008 sys-apps/tcng Samuli Suominen [EMAIL PROTECTED]04 Jan 2008 sys-apps/yard Samuli Suominen [EMAIL PROTECTED]04 Jan 2008 sys-libs/gi-detect Samuli Suominen [EMAIL PROTECTED]04 Jan 2008 x11-misc/fluxspace Samuli Suominen [EMAIL PROTECTED]04 Jan 2008 x11-misc/fluxter Samuli Suominen [EMAIL PROTECTED]04 Jan 2008 x11-themes/ximian-artwork Samuli Suominen [EMAIL PROTECTED]04 Jan 2008 x11-wm/flwmSamuli Suominen [EMAIL PROTECTED]04 Jan 2008 table tr thPackage:/th thRemoval date:/th thContact:/th /tr tr tiuri link=http://packages.gentoo.org/packages/?category=dev-java;name=cairo-java;dev-java/cairo-java/uri/ti ti04 Dec 2007/ti timail link=[EMAIL PROTECTED]Petteri Räty/mail/ti /tr tr tiuri link=http://packages.gentoo.org/packages/?category=dev-java;name=glib-java;dev-java/glib-java/uri/ti ti04 Dec 2007/ti timail link=[EMAIL PROTECTED]Petteri Räty/mail/ti /tr tr tiuri link=http://packages.gentoo.org/packages/?category=dev-java;name=libgconf-java;dev-java/libgconf-java/uri/ti ti04 Dec 2007/ti timail link=[EMAIL PROTECTED]Petteri Räty/mail/ti /tr tr tiuri link=http://packages.gentoo.org/packages/?category=dev-java;name=libglade-java;dev-java/libglade-java/uri/ti ti04 Dec 2007/ti timail link=[EMAIL PROTECTED]Petteri Räty/mail/ti /tr tr tiuri link=http://packages.gentoo.org/packages/?category=dev-java;name=libgnome-java;dev-java/libgnome-java/uri/ti ti04 Dec 2007/ti timail link=[EMAIL PROTECTED]Petteri Räty/mail/ti /tr tr tiuri link=http://packages.gentoo.org/packages/?category=dev-java;name=libgtk-java;dev-java/libgtk-java/uri/ti ti04 Dec 2007/ti timail link=[EMAIL PROTECTED]Petteri Räty/mail/ti /tr tr tiuri link=http://packages.gentoo.org/packages/?category=dev-java;name=libvte-java;dev-java/libvte-java/uri/ti ti04 Dec 2007/ti timail link=[EMAIL PROTECTED]Petteri Räty/mail/ti /tr tr tiuri link=http://packages.gentoo.org/packages/?category=dev-java;name=sun-jaf-bin;dev-java/sun-jaf-bin/uri/ti ti04 Dec 2007/ti timail link=[EMAIL PROTECTED]Petteri Räty/mail/ti /tr tr tiuri link=http://packages.gentoo.org/packages/?category=dev-lang;name=ghc-bin;dev-lang/ghc-bin/uri/ti ti05 Dec 2007/ti timail link=[EMAIL PROTECTED]Duncan Coutts/mail/ti /tr tr tiuri link=http://packages.gentoo.org/packages/?category=app-editors;name=beaver;app-editors/beaver/uri/ti ti04 Jan 2008/ti timail link=[EMAIL PROTECTED]Samuli Suominen/mail/ti /tr tr tiuri link=http://packages.gentoo.org/packages/?category=app-portage;name=portagemaster;app-portage/portagemaster/uri/ti ti04 Jan 2008/ti timail link=[EMAIL PROTECTED]Samuli Suominen/mail/ti /tr
Re: [gentoo-dev] POSIX shell and portable
On Mon, 05 Nov 2007 23:18:43 + Roy Marples [EMAIL PROTECTED] wrote: paludis requires tr1-whatever libs 4.1 ships those, so you don't need to do anything there. Maybe one day Gentoo will have a PM that doesn't require any of that and is just written in C and sh, using POSIX libc where it can. Except it won't, because ebuilds require bash regardless of which package manager is being used. If you want to change that you'll have to rewrite the entire tree. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] POSIX shell and portable
On Tue, 2007-11-06 at 07:12 +, Ciaran McCreesh wrote: Except it won't, because ebuilds require bash regardless of which package manager is being used. If you want to change that you'll have to rewrite the entire tree. Az once said near enough the same thing about baselayout. And that's your view, your entitled to it, but it is not my view. Change a little bit here, a little bit there. Slowly does it. Yes, I know that a fair chunk of the tree will need a re-write, just in the same way that the init scripts got a re-write. It will take time, it will not happen magically over night. To think overwise is foolish :) But if the default shell remains bash but the PM had enough knobs on it so this could be changed (maybe per ebuild) in /etc then work *could* start. Thanks Roy -- [EMAIL PROTECTED] mailing list
