Re: [gentoo-dev] Monthly Gentoo Council Reminder for February
On 01 Feb 2007 05:30:01 Mike Frysinger [EMAIL PROTECTED] wrote: This is your monthly friendly reminder ! Same bat time (typically the 2nd Thursday at 2000 UTC), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. Some people requested that the acceptance of GLEP 23 gets reconfirmed by the council before I merge it into portage due to the changes it has received. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Hardened USE flag
On Tue, 06 Feb 2007 00:15:25 -0400 Luis Francisco Araujo [EMAIL PROTECTED] wrote: Hello World! I want to ask for suggestions and opinions for the best way to handle this bug: http://bugs.gentoo.org/show_bug.cgi?id=158434 [textrels in smalltalk shared librart libgst.so] I am usually very hesitant to add new use flags to the tree (unless they are *really* necessary or imply a great advantage.) ; though i am not sure here if anybody else would consider this a good recommendation for handling textrels. In general, we would urge maintainers to default to no-textrels for shared libraries; normally the performance impact is negligible (often the performance is better, overall). It would be worth obtaining some real statistics before deciding. Note that textrels in shared libraries are pretty much an x86-only thing. amd64 in particular does not tolerate textrels in shared libraries (PIC is cheaper on amd64). I was thinking more of a simple 'use hardened myconf= .. ' specific line for this ebuild; but it's probably a good idea offering to more developers the easy choice of this feature through a USE flag? I think 'use pic' would be more appropriate, because we're talking about whether we want position-independent code or not (but I defer to solar in these things). If it looks enough useful for many people; then i think we can proceed to implement it; if it will only be used by this ebuild; then i am already against it ;-) -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Hardened USE flag
On Monday 05 February 2007, Luis Francisco Araujo wrote: I am usually very hesitant to add new use flags to the tree (unless they are *really* necessary or imply a great advantage.) ; though i am not sure here if anybody else would consider this a good recommendation for handling textrels. why not just build pic for everyone on x86 ? define it'll hurt performance ... of course you take a small penalty for code being PIC, but i dont exactly see smalltalk being such a performance hardcore language to justify making it special I was thinking more of a simple 'use hardened myconf= .. ' specific line for this ebuild; but it's probably a good idea offering to more developers the easy choice of this feature through a USE flag? you would utilize the pic USE flag ... php does this because it, unlike smalltalk, is very performance critical, and so by default it builds as non-pic on x86 -mike pgp9ofiJDIMFV.pgp Description: PGP signature
Re: [gentoo-dev] Hardened USE flag
Mike Frysinger wrote: On Monday 05 February 2007, Luis Francisco Araujo wrote: I am usually very hesitant to add new use flags to the tree (unless they are *really* necessary or imply a great advantage.) ; though i am not sure here if anybody else would consider this a good recommendation for handling textrels. why not just build pic for everyone on x86 ? define it'll hurt performance ... of course you take a small penalty for code being PIC, but i dont exactly see smalltalk being such a performance hardcore language to justify making it special I was thinking more of a simple 'use hardened myconf= .. ' specific line for this ebuild; but it's probably a good idea offering to more developers the easy choice of this feature through a USE flag? you would utilize the pic USE flag ... php does this because it, unlike smalltalk, is very performance critical, and so by default it builds as non-pic on x86 -mike Thank everyone; I will go with the pic USE flag option then. -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Hardened USE flag
On Tuesday 06 February 2007, Luis Francisco Araujo wrote: I will go with the pic USE flag option then. maybe i wasnt clear ... USE=pic is meant for only certain cases, certainly not for general use ... i dont think smalltalk qualifies for this concession -mike pgpTh01b1eq6x.pgp Description: PGP signature
[gentoo-dev] media-tv/rivatv last rites
RepoMan sez: media-tv/rivatv/rivatv-0.8.6.ebuild: not migrated to modular X media-tv/rivatv/rivatv-0.8.6-r1.ebuild: not migrated to modular X At this point, no one cares so it's being punted. Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Network configuration and bash
Hi List As some of you may be aware, I've started work on baselayout-2 which is basically re-tooling it in C. One of the side goals is to eliminate the need for using bash. You'll be pleased to know that it's working well enough to boot Gentoo/FreeBSD. Now, this email isn't about the merits of bash, nor the fact that it's in base system profile so we can use it anyway, blah blah blah. embedded has a vested interest in not using bash and I have a personal interest as Gentoo/FreeBSD on Sparc64 takes a very long time to boot. This email is about network configuration. Before I joined Gentoo, network configuration was done in bash arrays like so (note, that the variable name was changed in baselayout-1.11) ifconfig_eth0=( 10.1.1.1 netmask 255.255.255.0 10.1.1.2 netmask 255.255.255.0 ) This is all well and good, but only bash and zsh can use it. Infact I'm guilty as I embraced arrays and used them as the basis for our entire network scripts. They have also served us well, but as they are also array based they will have to be re-written too. So, to free baselayout of forcing bash down our throats I/we am/are looking at re-writing our network setup, including configuration. Who's got any bright ideas for a new config then? Lets brain storm! Thanks Roy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Tue, Feb 06, 2007 at 06:17:16PM +, Roy Marples wrote: Hi List Hi Roy, [snip] So, to free baselayout of forcing bash down our throats I/we am/are looking at re-writing our network setup, including configuration. Who's got any bright ideas for a new config then? Lets brain storm! It is a good format and easy to write and parse in C, why change it ? Just tell people to stop treating config files like bash scripts and everything will be fine. Or am I missing something? - ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpVCA2ayOize.pgp Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
On Tue, 6 Feb 2007 19:27:40 +0100 Fernando J. Pereda [EMAIL PROTECTED] wrote: On Tue, Feb 06, 2007 at 06:17:16PM +, Roy Marples wrote: Hi List Hi Roy, [snip] So, to free baselayout of forcing bash down our throats I/we am/are looking at re-writing our network setup, including configuration. Who's got any bright ideas for a new config then? Lets brain storm! It is a good format and easy to write and parse in C, why change it ? Just tell people to stop treating config files like bash scripts and everything will be fine. Or am I missing something? Well, the stuff in /etc/init.d/ and /etc/conf.d will stay as shell scripts - just not bash specific scripts. The stuff that handles our networking maybe written in A.N. Other-Language (Mrs.), but keeping /etc/conf.d/net readable by a shell script does have advantages. Thanks Roy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Tue, 6 Feb 2007 19:09:26 + Roy Marples [EMAIL PROTECTED] wrote: | The stuff that handles our networking maybe written in A.N. | Other-Language (Mrs.), but keeping /etc/conf.d/net readable by a shell | script does have advantages. He didn't say make it not readable by a shell. He was suggesting making it in some format that is readable both by C and the shell -- that is to say, a subset of shell. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
Forgive me if this is just noise, but I just wanted to say I agree fully with ferdy. As I was reading Roy's email, and I looked at the net config sample he had in there, I thought well, what's actually wrong with this? Keeping it as is has the advantage that an upgrade/downgrade cycle wouldn't change much in functionality based on config, which is pretty good (ie, backwards compatibility). In this case, I'm not sure legacy is all that bad, simply because it's expressive and concise and easily understood :) thanks, -- Seemant Kulleen Developer, Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Tuesday 06 February 2007, Michael Hanselmann wrote: XML! Actually, no. For me, libconfig[1] turned out to be very easy to work with. Its config file format is easy to write by hand and the parser resides in the library. On a simialr note there's libconfuse[1], which uses one of the most common formats available: ini-like :) [1] http://www.nongnu.org/confuse/ -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... pgpYWPdBzIKuX.pgp Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
On Tue, 06 Feb 2007 14:18:43 -0500 Seemant Kulleen [EMAIL PROTECTED] wrote: Forgive me if this is just noise, but I just wanted to say I agree fully with ferdy. As I was reading Roy's email, and I looked at the net config sample he had in there, I thought well, what's actually wrong with this? Cannot be parsed by shells other than bash or zsh Keeping it as is has the advantage that an upgrade/downgrade cycle wouldn't change much in functionality based on config, which is pretty good (ie, backwards compatibility). In this case, I'm not sure legacy is all that bad, simply because it's expressive and concise and easily understood :) So you're saying we patch other shells to support bash arrays? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Tue, 6 Feb 2007 20:31:03 + Roy Marples [EMAIL PROTECTED] wrote: | On Tue, 6 Feb 2007 19:27:15 + | Ciaran McCreesh [EMAIL PROTECTED] wrote: | | On Tue, 6 Feb 2007 19:09:26 + Roy Marples [EMAIL PROTECTED] | wrote: | | The stuff that handles our networking maybe written in A.N. | | Other-Language (Mrs.), but keeping /etc/conf.d/net readable by a | shell | script does have advantages. | | He didn't say make it not readable by a shell. He was suggesting | making it in some format that is readable both by C and the shell -- | that is to say, a subset of shell. | | Right, and bash arrays are not shell | http://www.opengroup.org/onlinepubs/009695399/toc.htm Sure they're shell. They're just not POSIX. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
On Tue, 2007-06-02 at 20:34 +, Roy Marples wrote: Keeping it as is has the advantage that an upgrade/downgrade cycle wouldn't change much in functionality based on config, which is pretty good (ie, backwards compatibility). In this case, I'm not sure legacy is all that bad, simply because it's expressive and concise and easily understood :) So you're saying we patch other shells to support bash arrays? What so wrong with bash? Apart from the fact that its not included in the unmodified base system of FreeBSD? Last I checked, we add lots of Gentooish stuff already. And that its not friendly to tiny embedded systems, which dont use a complex and powerful init system like Gentoo's (but prefer very simple ash scripts). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Tue, 6 Feb 2007 20:58:52 + Ciaran McCreesh [EMAIL PROTECTED] wrote: | Right, and bash arrays are not shell | http://www.opengroup.org/onlinepubs/009695399/toc.htm Sure they're shell. They're just not POSIX. Maybe I should have been more clear. Anything in /etc/conf.d/ should be able to be read by a POSIX compliant shell. This means no arrays. At this point in time, the only thing that uses arrays in /etc/conf.d/net - or any other bashisms or non POSIX shell stuff is out net config. Hence the need to change it. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Tue, 06 Feb 2007 16:03:50 -0500 Olivier Crete [EMAIL PROTECTED] wrote: What so wrong with bash? Unsuited to an init system that wants to work everywhere, like embedded systems. Also, being tied to one shell causes problems when that shell breaks. Witness baselayout problems regarding bash-3.0, 3.1 and 3.2 Lastly, in my first email I said Now, this email isn't about the merits of bash, nor the fact that it's in base system profile so we can use it anyway, blah blah blah. embedded has a vested interest in not using bash and I have a personal interest as Gentoo/FreeBSD on Sparc64 takes a very long time to boot. I'm assuming you did't read that bit :) Thanks Roy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Tue, 6 Feb 2007 21:04:59 + Roy Marples [EMAIL PROTECTED] wrote: | On Tue, 6 Feb 2007 20:58:52 + | Ciaran McCreesh [EMAIL PROTECTED] wrote: | | Right, and bash arrays are not shell | | http://www.opengroup.org/onlinepubs/009695399/toc.htm | | Sure they're shell. They're just not POSIX. | | Maybe I should have been more clear. | | Anything in /etc/conf.d/ should be able to be read by a POSIX | compliant shell. This means no arrays. Why? What's wrong with requiring a shell that supports various features beyond what POSIX specifies? Granted, choice of shell is good, but not if it's at the expense of functionality or ease of use. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
On Tue, 2007-06-02 at 21:11 +, Roy Marples wrote: On Tue, 06 Feb 2007 16:03:50 -0500 Olivier Crete [EMAIL PROTECTED] wrote: What so wrong with bash? Unsuited to an init system that wants to work everywhere, like embedded systems. Also, being tied to one shell causes problems when that shell breaks. Witness baselayout problems regarding bash-3.0, 3.1 and 3.2 Lastly, in my first email I said Now, this email isn't about the merits of bash, nor the fact that it's in base system profile so we can use it anyway, blah blah blah. embedded has a vested interest in not using bash and I have a personal interest as Gentoo/FreeBSD on Sparc64 takes a very long time to boot. I'm assuming you did't read that bit :) Actually I did, but I really dont see what kind of embedded system would be complex enough to require the Gentoo init system, yet not enough to use bash. And I don't see why g/fbsd sparc64 is problematic? Or is it just that you have a 1995 vintage system and you want to run Gentoo on it? -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Tue, 6 Feb 2007 21:11:31 + Roy Marples [EMAIL PROTECTED] wrote: | Now, this email isn't about the merits of bash, nor the fact that | it's in base system profile so we can use it anyway, blah blah blah. | embedded has a vested interest in not using bash and I have a | personal interest as Gentoo/FreeBSD on Sparc64 takes a very long | time to boot. | | I'm assuming you did't read that bit :) I think it's more that you're expected to justify *why* the bash requirement is so bad, given the cost of changing. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
On Tue, 6 Feb 2007 21:14:49 + Ciaran McCreesh [EMAIL PROTECTED] wrote: Why? What's wrong with requiring a shell that supports various features beyond what POSIX specifies? Granted, choice of shell is good, but not if it's at the expense of functionality or ease of use. H, just how many features should a config file have beyond the setting of variables? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Tue, 6 Feb 2007 21:28:04 +
Ciaran McCreesh [EMAIL PROTECTED] wrote:
I think it's more that you're expected to justify *why* the bash
requirement is so bad, given the cost of changing.
1) Lack of choice.
Gentoo is all about giving the user choice. baselayout even supports
other init systems when requested.
2) Speed.
Bash is one of the slowest shells around for looping.
However, it also requires less forking due to it's nice built-ins. This
does of course only work with bash and not other shells.
3) What's the cost of *not* changing away from bash?
I would say that bash is the best shell around in terms of features and
ease of use, however that is not without cost. That cost is new bash
versions consistently breaking baselayout, ebuilds and configure files.
4) Size.
Because bash has all these nice features it's large, hence unsuitable
for low memory or low disk space environments.
5) I'm *just* talking about config files here.
If users want to run bash, that's fine and I won't stop them. They can
also use bash in their init script if they so wish as I plan to support
something like so
depend() {
shell bash
}
And voila, problem solved. Of course, that's just an idea I just had.
However, I also think that baselayout provided services should not
require bash for the above reasons, hence the need for a new config.
Hopefully I've justified this enough :)
Thanks
Roy
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Tue, 6 Feb 2007 19:09:26 + Roy Marples [EMAIL PROTECTED] wrote: The stuff that handles our networking maybe written in A.N. Other-Language (Mrs.), but keeping /etc/conf.d/net readable by a shell script does have advantages. You need to define what shell (or subset) you want to parse it. 'sh' itself varies from platform to platform. The one we have is a softlink to bash so doesn't make any difference for Gentoo Linux except for limiting what can be written. I just tried variable redirection for example (which can be used to implement pseudo-arrays without using eval) - I was surprised it works in sh here - dunno if it works in BSD sh (doesn't on busybox). What you have on FreeBSD may be different from what's on Solaris. Perhaps busybox sh might be a practical set to choose, for basic posix compliance. You could simply do something like: ifconfig_eth0=\ 10.1.1.1 netmask 255.255.255.0;\ 10.1.1.2 netmask 255.255.255.0 which means standard shell interpretation doesn't lose information, even if it's actually normally parsed by something else (chose ';' as a separator since ':' is used in ipv6 strings). It seems to me that the problem you're trying to solve, is the implementation of baselayout on restricted systems. Reducing all init.d/conf.d and so on to a common denominator for everyone isn't necessarily the best way forward. A different approach could be to provide more than one baselayout; one for large systems, where expecting to have bash available isn't such a big deal, and one for limited systems, restricted to busybox-standard sh. Actually I kinda assumed that's what baselayout-lite was all about... -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
On Tuesday 06 February 2007, Roy Marples wrote: Hopefully I've justified this enough :) justified what ? this thread started off killing bash array requirements in the network config file and now it looks like your killing the shell everywhere ? to be honest, unless the new code is really good, it's still going to be not suitable for real embedded systems ... sure, i run Gentoo on all my embedded machines, but lets be honest, these arent even close to real embedded -mike pgpIvD4ML3jyD.pgp Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
On Tuesday 06 February 2007, Kevin F. Quinn wrote: You need to define what shell (or subset) you want to parse it. 'sh' itself varies from platform to platform. our standard has always (always is relative here; let's say current) been the bash superset of POSIX ... if a request comes up where someone wants to change code because it breaks in their shell but the code in question is POSIX compliant, the answer is simple: blow me if the request is reasonable like stop using some bashism in favor of the POSIX form and the change isnt invasive, then sure we'll generally make the change -mike pgpG0S2atZLMK.pgp Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
Or perhaps, Something a little more explicit might work? In instances such as the ifconfig lines, it's to create eth0 aliases (such as eth0:0), so perhaps that could look like: ifconfig_eth0:0 = 10.1.1.1 netmask 255.255.255.0 ifconfig_eth0:1 = 10.1.1.2 netmask 255.255.255.0 For uses that really do require a list (such as modules), something like: modules = wpa_supplicant, ifconfig or redefinition: modules = wpa_supplicant modules = ifconfig might work? If the comma separated syntax is acceptable, it may be that brackets around it are acceptable too, in which case the bash syntax is fine. If the normal shells will still require *some* form of processing to deal with the list, could they not be given processing to deal with lists that bash already has builtin? Mike 5:) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Tue, 2007-02-06 at 19:42 -0500, Mike Frysinger wrote: On Tuesday 06 February 2007, Kevin F. Quinn wrote: You need to define what shell (or subset) you want to parse it. 'sh' itself varies from platform to platform. our standard has always (always is relative here; let's say current) been the bash superset of POSIX ... if a request comes up where someone wants to change code because it breaks in their shell but the code in question is POSIX compliant, the answer is simple: blow me if the request is reasonable like stop using some bashism in favor of the POSIX form and the change isnt invasive, then sure we'll generally make the change /me likes the direction Roy is heading with this. -mike -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Tue, 6 Feb 2007 23:26:32 +
Roy Marples [EMAIL PROTECTED] wrote:
On Tue, 6 Feb 2007 21:28:04 +
Ciaran McCreesh [EMAIL PROTECTED] wrote:
I think it's more that you're expected to justify *why* the bash
requirement is so bad, given the cost of changing.
1) Lack of choice.
Gentoo is all about giving the user choice. baselayout even supports
other init systems when requested.
Surely you would provide choice by providing different baselayout
packages; one tailored for embedded systems that only have busybox, one
for general purpose use, etc. That's what the virtual is for, isn't it?
2) Speed.
Bash is one of the slowest shells around for looping.
However, it also requires less forking due to it's nice built-ins.
This does of course only work with bash and not other shells.
Restricting everything to 'sh' I think is more likely to slow things
down than anything else. Apart from the forking issue that you
mention, builtins are different - '[' for example is about 30% slower
than '[[' in bash (which is what's implementing sh on Gentoo Linux). I
wonder how much time would be saved on Gentoo Linux by replacing [ with
[[ throughout the init scripts; maybe a percentage point?
If there really is a big speed penalty from using bash on BSD compared
to the native shell, wouldn't it be better to supply a Gentoo/FreeBSD
baselayout? They don't have to be completely independent; smart use of
the vcs would allow you to share scripts between baselayout branches,
with specific variants where it makes a difference.
3) What's the cost of *not* changing away from bash?
I would say that bash is the best shell around in terms of features
and ease of use, however that is not without cost. That cost is new
bash versions consistently breaking baselayout, ebuilds and configure
files.
w.r.t new bash versions, we should certainly be conservative in marking
new versions stable. It's worth noting the breakage isn't always
100% the fault of bash. The recent problem with '=~' and quoting for
example is down to glibc behaving differently to everyone else's libc
when it comes to accepting quoted characters for the regex interfaces
(a point where the POSIX standard is open to interpretation).
4) Size.
Because bash has all these nice features it's large, hence unsuitable
for low memory or low disk space environments.
But you only get one bash text image in memory at any one time (~825k).
So space isn't a real issue, except on small-memory systems.
5) I'm *just* talking about config files here.
If users want to run bash, that's fine and I won't stop them. They can
also use bash in their init script if they so wish as I plan to
support something like so
depend() {
shell bash
}
Making that sort of requirement explicit is a good idea. I wouldn't use
'depend()', as in init scripts it's quite cleanly only to do with the
order of services. You could make it an option to runscript:
#!/bin/runscript --shell=/bin/bash
or something along those lines - the shebang is clearly all about how
the script is executed, and the shell used falls nicely into that.
And voila, problem solved. Of course, that's just an idea I just had.
However, I also think that baselayout provided services should not
require bash for the above reasons, hence the need for a new config.
I think the argument for conf.d files is better than that for init.d
scripts; you could have multiple baselayout setups that share conf.d
file formats.
--
Kevin F. Quinn
signature.asc
Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
On Tue, 6 Feb 2007 19:39:03 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: On Tuesday 06 February 2007, Roy Marples wrote: Hopefully I've justified this enough :) justified what ? this thread started off killing bash array requirements in the network config file and now it looks like your killing the shell everywhere ? No, I'm just interesting in killing bash array requirements in the network config file. Once that is done, then you can use whatever shell you wish as far as the init scripts allow, which will hopefully be all of them in portage. to be honest, unless the new code is really good, it's still going to be not suitable for real embedded systems ... sure, i run Gentoo on all my embedded machines, but lets be honest, these arent even close to real embedded -mike I cannot argue that as I have no embedded systems of which to speak. However, some users and devs who use embedded systems have expressed an interest so I'll let them argue as they will. Thanks Roy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Tue, 6 Feb 2007, Roy Marples wrote: This email is about network configuration. Before I joined Gentoo, network configuration was done in bash arrays like so (note, that the variable name was changed in baselayout-1.11) ifconfig_eth0=( 10.1.1.1 netmask 255.255.255.0 10.1.1.2 netmask 255.255.255.0 ) This is all well and good, but only bash and zsh can use it. That's not true. Only bash and zsh can *source* it. Aside from the fact that most other shells don't have any way of storing the results of reading such a file in an accessible way, that format is easy enough to parse with a bit of sed. Who's got any bright ideas for a new config then? Lets brain storm! If it's necessary to change at all, I'd vote for sections in square brackets, applying to everything until the next square bracket, and lines with a key, followed by a ':' or '=', followed by optional whitespace, followed by any number of values, optionally in quotes with backslash-escaped quotes and backslashes, separated by whitespace, with the value lists for duplicate keys being concatenated. It's not hard to parse (assuming, again, that you have some way to store the results), users coming from Windows can write it as ini files, users who like Java can write it as resource files, and old-school Unix types can write RFC822 headers. And they're all mutually comprehensible if the parser is just reasonably lenient. -Daniel *This .sig left intentionally blank* -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Tuesday 06 February 2007, Roy Marples wrote: No, I'm just interesting in killing bash array requirements in the network config file. you need to kill them everywhere then ... network config isnt the only file that utilizes arrays -mike pgpj1mYCh71a3.pgp Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
Roy Marples [EMAIL PROTECTED] writes: H, just how many features should a config file have beyond the setting of variables? In the case of networking, the ability to define the functions for the various hooks. In most systems these will not be needed, but where policy routing etc is used the hooks need to be defined somewhere, but not necessarily the configuration file as they are at the moment. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
Roy Marples napsal(a):
This email is about network configuration. Before I joined Gentoo,
network configuration was done in bash arrays like so (note, that the
variable name was changed in baselayout-1.11)
ifconfig_eth0=(
10.1.1.1 netmask 255.255.255.0
10.1.1.2 netmask 255.255.255.0
)
This is all well and good, but only bash and zsh can use it. Infact I'm
guilty as I embraced arrays and used them as the basis for our entire
network scripts. They have also served us well, but as they are also
array based they will have to be re-written too.
To be honest, I hate the idea of rewriting the network config; being
able to specify things like
config_eth0=( 10.1.1.{1..10}/24 brd + )
(yes, it really expands correctly and works!) is extremely useful and
something you don't find in any other distro out there last time I've
checked. You can assign tons of IP address on a single line, or just
with a couple of lines if you need different subnets, instead of going
thru the boring and error-prone task of specifying every single address
separately.
Why kill such useful features just to get rid of arrays and bash?
Kevin F. Quinn napsal(a):
Surely you would provide choice by providing different baselayout
packages; one tailored for embedded systems that only have busybox,
one for general purpose use, etc. That's what the virtual is for,
isn't it?
+1
--
Best regards,
Jakub Moc
mailto:[EMAIL PROTECTED]
GPG signature:
http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E
Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E
... still no signature ;)
signature.asc
Description: OpenPGP digital signature
[gentoo-portage-dev] recent changes in the way pkgsplit() and company work
Sorry, but I didn't have an internet connection for January to notice but when I upgraded to 2.1.2-r7 pkgsplit, catpkgsplit, catsplit no longer accepted ebuild strings with any atoms. Porthole was crashing in several places. I have changed portholes coding to work around it, but there are several more bugs for me to fix before considering it for a new release (a few unfinished features too). My main question is what approximate time frame is if any being considered for stabilizing the 2.1.2 version. I will need to make sure I have a release ready for porthole users. Also, I had copied a little code from gentoolkit which also puked at the change in strictness. I don't know if that has been changed already. It was in split_package_name(). It was called from find_best_match() called from get_system_pkgs(). Brian -- gentoo-portage-dev@gentoo.org mailing list
