On Thu, 2006-07-20 at 11:11 +0000, Alex wrote: > > There was also a bug in catalyst that caused "xdm" to be added to the > > default runlevel for "generic-livecd" which was never how it was > > designed. Instead, the specific session was *supposed* to be started > > via "startx" as the user. > > so I do not understand the sense livecd/xdm option. Does it only change > the variable in /etc/rc.conf?
Correct. > > What if you have more than one user and don't want any to login? > > Well, I just get irritated by the template-specfile. But if it would > automatically login by default, I would just keep the livecd/xdm option > blank in this case. Then file a bug with suggested changes. People who get "irritated" but don't bother to take a few minutes to try to *fix* the problem don't help us any. The truth is that we code catalyst for Release Engineering, first and foremost. The only reason pretty much *anything* works for non-releases is because interested users have supplied patches or given good ideas. Doing catalyst support for non-releases takes a significant enough portion of my time that I sometimes wish we'd never bothered to make an ebuild for it. ;] > > What if you don't want a particular session to be the default and want > > the user to choose? > > > > Just specify no xsession (that would by _my_ way) That would break horribly considering how the automatic login code is written. Instead, you'd get twm, rather than sitting at the display manager. Remember that things built with catalyst act *just* like a real Gentoo system does, configuration and all. I think that this is the thing lost on catalyst users the most. We expect *you* to make it do what you want, rather than for us to make it do what you want. In the old days of catalyst, we required people to make their own archscript/runscript to make changes, because catalyst only had a single function, to build releases. Things have changed quite a bit, but the underlying principle is still very similar. If you want something changed, write a patch. If it isn't a "bug" in the code, we're not very likely to work on it unless we find some spare time, which is rare, especially for Release Engineering. > I like the flexibility of gentoo and its sub-projects, without it I > probably wouldn't use it. I just get irritated by the comments in the > template-specfile, but you have said it is out of date, so I think this > is clarified (for me), except the sense of livecd/xdm and > livecd/xsession (I don't understand it). That wasn't exactly what I meant. It was out of date with the current state of the code at that time. The code was the problem. The template comments are 100% spot-on to what the design should be. It was a code refactoring done during this release cycle that *ever* caused "xdm" to be added to the default runlevel for non-release builds. It was a bug. The livecd/xdm and livecd/xsession only set the defaults for these variables on non-release builds. It is up to you to add "xdm" to your default runlevel if you want it to start at boot, as well as perform any configuration on the display manager and any X sessions that you wish customized. The general rule of thumb with catalyst is you have to do it yourself. Don't assume that anything is done for you. Unfortunately, more and more non-developers have been using catalyst. By that, I don't mean users, I mean people who don't look at the code to see what it does and doesn't do on their own. Right now, there is exactly one person actively maintaining catalyst. There are only two maintainers total. Because of this, the code changes much faster than any documentation does, except for the templates, which are kept (mostly) in sync with the actual code. In cases where the templates and code are not in sync, it is likely a bug in the code, and not the template. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
