1 |
On Thursday 03 January 2008, Roy Marples wrote: |
2 |
> On Thu, 2008-01-03 at 10:49 -0500, Mike Frysinger wrote: |
3 |
> > while is_older_than is negotiable, removing KV_* is not. those are |
4 |
> > pretty tight utility functions which duplication in $random-packages will |
5 |
> > only lead to problems (especially considering the history of making sure |
6 |
> > they were coded right). they've weathered quite a long time and should |
7 |
> > be pretty much unchanged, so there is no good reason to omit them. there |
8 |
> > is no overhead of having them available and maintaining them. |
9 |
> |
10 |
> KV_* only makes sense when dealing with Linux version numbers are |
11 |
> they're always numeric. The BSD's on the other hand include textual |
12 |
> elemants too. |
13 |
> uname -r on this machine is 7.0-RC1. |
14 |
|
15 |
that's incorrect ... linux uname's often have textual content as well |
16 |
(-mm, -git, -rc, -fooie). the KV_* functions only parse out the relevant |
17 |
values and in the case of the linux kernel, that is: |
18 |
major.minor.micro[.stable] |
19 |
|
20 |
> luckily, baselayout-2 as it stands in portage only exports the KV_to_int |
21 |
> function so that's the only one we should be dealing with. |
22 |
|
23 |
i'm not so sure ... the other functions are trivial to implement and |
24 |
considering KV_to_int is implemented based on those ... no reason to cull the |
25 |
functions when they are certainly useful. |
26 |
|
27 |
> So, the question is, do we want to maintain one massive KV_to_int that |
28 |
> has different code paths for uname -s output, or get function.sh to |
29 |
> include an OS specific file we supply just for this one function? |
30 |
|
31 |
how you want to architect it in the backend is up to you, but the latter |
32 |
probably makes more sense. my concern is for the frontend ("API") and that |
33 |
is that the functions need to be exported. |
34 |
|
35 |
> Or just put the function in modules-update and udev as they are the only |
36 |
> two applications that use it. |
37 |
|
38 |
no, that is most certainly not where we want to go |
39 |
|
40 |
> > if you want a cleaner interface for is_older_than, then we could hammer |
41 |
> > that out, but if it's just a pass through to a C applet, then leaving it |
42 |
> > alone makes sense. |
43 |
> |
44 |
> Currently it's neither as it's been integrated into the librc dependency |
45 |
> code. Again, the only consumer of this function is now modules-update. |
46 |
|
47 |
that may simply be because the only people who have been tracking the code |
48 |
closely are you and me ... considering the nature of the function, it sounds |
49 |
like a good function other things can leverage as it provides make-style |
50 |
timestamp tracking for conditionally updating of files. |
51 |
|
52 |
> > > > I also notice that the timezone of clock is gone, any alternative? |
53 |
> > > > Also the network dependency of stopping/starting services when |
54 |
> > > > network is unavailable/available is gone, any alternative? |
55 |
> > > |
56 |
> > > The timezone was variable was just a hack for the timezone ebuild to |
57 |
> > > update /etc/localtime if it's not a symlink. I'm striving to remove all |
58 |
> > > "Gentooisms" from it so that it really is platform neutral. |
59 |
> > |
60 |
> > you view the purpose of TIMEZONE incorrectly. it was a central script |
61 |
> > parasable location to store the system timezone. every distribution out |
62 |
> > there does it somehow. the way for OpenRC to do it is set the variable |
63 |
> > in /etc/conf.d/clock. the fact that currently the timezone ebuild is the |
64 |
> > only one using it is irrelevant. |
65 |
> |
66 |
> Then I suggest that conf.d/clock is the wrong place for it as if it was |
67 |
> set there then it implies that `/etc/init.d/clock start` would change to |
68 |
> that timezone, which is clearly not the case. |
69 |
|
70 |
that's fair. i'd also add that forcing the value into conf.d/clock forces a |
71 |
reliance on openrc and prevents alternative init packages (which we've seen |
72 |
people use). i know debian uses /etc/localtime, any one know what other |
73 |
distro conventions are in use out there ? |
74 |
-mike |