On Thursday 03 January 2008, Roy Marples wrote:
> 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.

that's incorrect ... linux uname's often have textual content as well 
(-mm, -git, -rc, -fooie).  the KV_* functions only parse out the relevant 
values and in the case of the linux kernel, that is:
major.minor.micro[.stable]

> 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.

i'm not so sure ... the other functions are trivial to implement and 
considering KV_to_int is implemented based on those ... no reason to cull the 
functions when they are certainly useful.

> 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?

how you want to architect it in the backend is up to you, but the latter 
probably makes more sense.  my concern is for the frontend ("API") and that 
is that the functions need to be exported.

> Or just put the function in modules-update and udev as they are the only
> two applications that use it.

no, that is most certainly not where we want to go

> > 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.

that may simply be because the only people who have been tracking the code 
closely are you and me ... considering the nature of the function, it sounds 
like a good function other things can leverage as it provides make-style 
timestamp tracking for conditionally updating of files.

> > > > 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.

that's fair.  i'd also add that forcing the value into conf.d/clock forces a 
reliance on openrc and prevents alternative init packages (which we've seen 
people use).  i know debian uses /etc/localtime, any one know what other 
distro conventions are in use out there ?
-mike