Re: [gentoo-dev] Re: Baselayout-2 progress?
Bernd Steinhauser wrote: > Duncan schrieb: > > Bernd Steinhauser <[EMAIL PROTECTED]> posted > > > > > What about the timezone? > > > Baselayout had a setting for the timezone in /etc/conf.d/clock. > > > baselayout-2.0.0 > > > + openrc doesn't seem to have that. Not needed? > > > > > > > Not needed indeed. > [...] > Then there should be a note, that this setting is deprecated. Please observe that the setting from /etc/conf.d/clock is not only used by baselayout but also by the sys-libs/timezone-data ebuild: It uses this setting to copy to /etc/timezone (IIRC the symlink was officially deprecated, because it might point to a different partition). So the setting might be deprecated for openrc, but it is not deprecated for gentoo. Regards Martin -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Baselayout-2 progress?
Duncan schrieb: Bernd Steinhauser <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 01 Mar 2008 23:50:09 +0100: What about the timezone? Baselayout had a setting for the timezone in /etc/conf.d/clock. baselayout-2.0.0 + openrc doesn't seem to have that. Not needed? Not needed indeed. The previous setting caused confusion because changing it didn't actually change the timezone (this isn't the place for the technical details). Now, the clock config file simply sets local or UTC, while the timezone is set using the standard glibc /etc/localtime -> /usr/share/zoneinfo/ symlink or the TZ environmental variable (see the tzset and hwclock manpages among others). Then there should be a note, that this setting is deprecated. Currently it only says: 'If you want to manage /etc/localtime yourself, set this to "".' If there is a note, that this setting isn't used anymore it won't make users, that still have it set wonder why an etc update wants to remove it. Bernd -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Baselayout-2 progress?
Bernd Steinhauser <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 01 Mar 2008 23:50:09 +0100: > What about the timezone? > Baselayout had a setting for the timezone in /etc/conf.d/clock. > baselayout-2.0.0 > + openrc doesn't seem to have that. Not needed? Not needed indeed. The previous setting caused confusion because changing it didn't actually change the timezone (this isn't the place for the technical details). Now, the clock config file simply sets local or UTC, while the timezone is set using the standard glibc /etc/localtime -> /usr/share/zoneinfo/ symlink or the TZ environmental variable (see the tzset and hwclock manpages among others). -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Baselayout-2 progress?
Roy Marles <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 01 Mar 2008 10:50:50 +: > As others pointed out, this is a package manager issue and those > blockers are there because of this. Not an OpenRC issue as such ;) > > Thanks ... And thank /you/! =8^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Baselayout-2 progress?
On Saturday 01 March 2008 02:08:44 Duncan wrote: > Is direct upgrade from previous baselayout-2.0.0-rcX going to be > supported? Existing configs should work just fine - with the exception of the modules config. It's been moved to /etc/conf.d/modules instead of the /etc/modules.autoload.d folder. There is no automated migration as complex setups would go wrong. > I was running that for some time and just now added and > upgraded to the via layman version. There's a blocker, of course, as > openrc is now providing most of the files that baselayout did. > > The problem is that unmerging the old 2.0.0-rcX baselayout in ordered to > resolve the blockage is SCARY, since it leaves the system basically > unbootable until the new setup is merged and at least basically > configured. There's also the issue of not knowing for sure just what's > going to still be around in terms of config files and the like, since > unmerging baselayout isn't exactly an everyday thing. > > FWIW, I took the jump anyway, and the etc-update seemed to go reasonably > well, but I've not rebooted yet... As others pointed out, this is a package manager issue and those blockers are there because of this. Not an OpenRC issue as such ;) Thanks Roy -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Baselayout-2 progress?
Doug Klima <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Fri, 29 Feb 2008 23:59:06 -0500: >> Is direct upgrade from previous baselayout-2.0.0-rcX going to be >> supported? I was running that for some time and just now added and >> upgraded to the via layman version. There's a blocker, of course, as >> openrc is now providing most of the files that baselayout did. > > You just answered your own question. If another package now provides > files that an existing package provides, they must be blockers. Thus the "of course"... > Considering baselayout-2.0.0_rcX was a masked version and never > recommended, it's also not in the direct upgrade path. The proper > upgrade is what you've detailed out below. Such are the risks when you > unmask a package and install it on your machine. Which is why I'm not particularly complaining, just asking. Practically speaking, while it's not required by any means, some devs choose to acknowledge the symbiotic relationship between pre-release testers willing to take that risk and do the work to find and file bugs, thus helping to make the general release far less buggy, and the devs who depend on such testers for that function. The testers do a favor for the devs with all that early testing and bug filing (sometimes with patches), and many devs choose to return it by providing a working upgrade path from the pre-releases to the general release. Among other things, it makes for happier testers, who are then likely to be repeat testers, the next time an upgrade comes along. It's also worth mentioning that a call for testers went out, so it's not as if those that answered it, particularly if the DID actively look for and file bugs as they found them, were doing it entirely of their own accord. Again, it's doing the developer a favor, so it's a nice gesture if the developer chooses to return the favor by smoothing the upgrade path. Not something he has to do, but something he /can/ do, to increase the chances of folks who already know the process again taking him up on the invitation, the next time he needs something tested. =8^) So anyway, I thought it was worth asking about, in case it had slipped his mind or he hadn't thought of it. No big deal either way, but it'd be a nice gesture if it's not too difficult to setup. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Baselayout-2 progress?
Duncan wrote: Roy Marples <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Fri, 29 Feb 2008 17:07:17 +: On Friday 29 February 2008 16:15:51 Ed W wrote: On the other hand since there still isn't a masked ebuild in portage (and I seem some notes on my on Roy's site) then I have to assume that in fact we are still a good way away from calling it a replacement and starting to push it out to users? It's actually been very stable and usable for a long time. It's not, and never will be a 100% drop in replacement for everything baselayout provides, but it's very very compatible. Is direct upgrade from previous baselayout-2.0.0-rcX going to be supported? I was running that for some time and just now added and upgraded to the via layman version. There's a blocker, of course, as openrc is now providing most of the files that baselayout did. You just answered your own question. If another package now provides files that an existing package provides, they must be blockers. Considering baselayout-2.0.0_rcX was a masked version and never recommended, it's also not in the direct upgrade path. The proper upgrade is what you've detailed out below. Such are the risks when you unmask a package and install it on your machine. The problem is that unmerging the old 2.0.0-rcX baselayout in ordered to resolve the blockage is SCARY, since it leaves the system basically unbootable until the new setup is merged and at least basically configured. There's also the issue of not knowing for sure just what's going to still be around in terms of config files and the like, since unmerging baselayout isn't exactly an everyday thing. FWIW, I took the jump anyway, and the etc-update seemed to go reasonably well, but I've not rebooted yet... -- Doug Klima <[EMAIL PROTECTED]> http://dev.gentoo.org/~cardoe/ -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Baselayout-2 progress?
Roy Marples <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Fri, 29 Feb 2008 17:07:17 +: > On Friday 29 February 2008 16:15:51 Ed W wrote: >> On the other hand since there still isn't a masked ebuild in portage >> (and I seem some notes on my on Roy's site) then I have to assume that >> in fact we are still a good way away from calling it a replacement and >> starting to push it out to users? > > It's actually been very stable and usable for a long time. It's not, and > never will be a 100% drop in replacement for everything baselayout > provides, but it's very very compatible. Is direct upgrade from previous baselayout-2.0.0-rcX going to be supported? I was running that for some time and just now added and upgraded to the via layman version. There's a blocker, of course, as openrc is now providing most of the files that baselayout did. The problem is that unmerging the old 2.0.0-rcX baselayout in ordered to resolve the blockage is SCARY, since it leaves the system basically unbootable until the new setup is merged and at least basically configured. There's also the issue of not knowing for sure just what's going to still be around in terms of config files and the like, since unmerging baselayout isn't exactly an everyday thing. FWIW, I took the jump anyway, and the etc-update seemed to go reasonably well, but I've not rebooted yet... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-dev@lists.gentoo.org mailing list
