On Thu, 2008-01-03 at 10:49 -0500, Mike Frysinger wrote: > while is_older_than is negotiable, removing KV_* is not. those are pretty > tight utility functions which duplication in $random-packages will only lead > to problems (especially considering the history of making sure they were > coded right). they've weathered quite a long time and should be pretty much > unchanged, so there is no good reason to omit them. there is no overhead of > having them available and maintaining them.
KV_* only makes sense when dealing with Linux version numbers are they're always numeric. The BSD's on the other hand include textual elemants too. uname -r on this machine is 7.0-RC1. luckily, baselayout-2 as it stands in portage only exports the KV_to_int function so that's the only one we should be dealing with. So, the question is, do we want to maintain one massive KV_to_int that has different code paths for uname -s output, or get function.sh to include an OS specific file we supply just for this one function? Or just put the function in modules-update and udev as they are the only two applications that use it. > if you want a cleaner interface for is_older_than, then we could hammer that > out, but if it's just a pass through to a C applet, then leaving it alone > makes sense. Currently it's neither as it's been integrated into the librc dependency code. Again, the only consumer of this function is now modules-update. > > > I also notice that the timezone of clock is gone, any alternative? > > > Also the network dependency of stopping/starting services when network > > > is unavailable/available is gone, any alternative? > > > > The timezone was variable was just a hack for the timezone ebuild to > > update /etc/localtime if it's not a symlink. I'm striving to remove all > > "Gentooisms" from it so that it really is platform neutral. > > you view the purpose of TIMEZONE incorrectly. it was a central script > parasable location to store the system timezone. every distribution out > there does it somehow. the way for OpenRC to do it is set the variable > in /etc/conf.d/clock. the fact that currently the timezone ebuild is the > only one using it is irrelevant. Then I suggest that conf.d/clock is the wrong place for it as if it was set there then it implies that `/etc/init.d/clock start` would change to that timezone, which is clearly not the case. Thanks Roy -- [EMAIL PROTECTED] mailing list
