From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JCiS3-00053h-Rn for garchives@archives.gentoo.org; Wed, 09 Jan 2008 21:27:08 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9B5A3E0739; Wed, 9 Jan 2008 21:26:26 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 4CC12E0739 for ; Wed, 9 Jan 2008 21:26:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 38BC464FD2; Wed, 9 Jan 2008 21:26:25 +0000 (UTC) From: Mike Frysinger Organization: wh0rd.org To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] OpenRC available for testing. Date: Wed, 9 Jan 2008 16:26:24 -0500 User-Agent: KMail/1.9.7 Cc: Roy Marples References: <1199191260.2786.9.camel@uberpc.marples.name> <200801031049.02813.vapier@gentoo.org> <1199384389.28193.24.camel@localhost> In-Reply-To: <1199384389.28193.24.camel@localhost> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1741701.rf3pHGmSmd"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200801091626.24681.vapier@gentoo.org> X-Archives-Salt: f97763d2-3040-473d-b1d5-9ff53dfa9b4c X-Archives-Hash: aab10387cd936301aaed06d17471e6d1 --nextPart1741701.rf3pHGmSmd Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 wi= ll > > 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. the= re > > 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=20 (-mm, -git, -rc, -fooie). the KV_* functions only parse out the relevant=20 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=20 considering KV_to_int is implemented based on those ... no reason to cull t= he=20 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=20 probably makes more sense. my concern is for the frontend ("API") and that= =20 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= =20 closely are you and me ... considering the nature of the function, it sound= s=20 like a good function other things can leverage as it provides make-style=20 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 a= ll > > > "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 t= he > > 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=20 reliance on openrc and prevents alternative init packages (which we've seen= =20 people use). i know debian uses /etc/localtime, any one know what other=20 distro conventions are in use out there ? =2Dmike --nextPart1741701.rf3pHGmSmd Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (GNU/Linux) iQIcBAABAgAGBQJHhTwAAAoJEEFjO5/oN/WBIp8QAJPqV1bZmIaCOaKY0VYxV2FJ fWwvu2uxbcyq0ushlDsNVHPTENCHr8FjrzaMx2MvQr7QZpd6r0g63JP8F4gX+Uon F+ZVlAyo7Ba7RBKdnwaU4azUH9aw8wtv5OOttZOd+GAujZRwxZILwToH8ESasn5R 41vw6paf5kkXe7UlWnfRvo2+SmDQGk7ONnGGMQekVIjtxSvn4idfpCQIbTjUKBgJ pZY2J/3fjJ+6H8SLPqT97twuUL5Bn0KMrq75/d3Ot/oNk2c/4vS2seVmdsVxSB6b Zj/xYo1Q6O24hohnN7v73kgjMw4LSDomR7wXo5R2ETUXdoi0Q7Cv1HE6kQlQuTeH Xayp0M2kbN3/UAPgdrmbJH6WiZJfcPWGdr/INrIs1rfdjbjB5amXWx41+sHAUtbf IWQgOIvOyrtjm/qlSdoOmV0JLbdSTErgx1zLxDTqCB9jUWKv4lM4uGgEJaR6nUwM E/eW18Yio/MocASSPzw5Y48XSQ6FicVEgXPj9X0iEZw295DAaYdg+JbbFm/96z7y bqCFiEG8N1L54tUmV1U/6goow7uWIQURQv+tfw6oV+bMRxTM6I3DDqPCruRBr82V mf5HYEBtHU3gzZBSfs22N+sSNMIYCHiL/Fyx769m2N0ABlsDNwUaCi+8PgZsTi3A B+IeDukMwUAla+1AlFh0 =r/Iq -----END PGP SIGNATURE----- --nextPart1741701.rf3pHGmSmd-- -- gentoo-dev@lists.gentoo.org mailing list